Häufig gestellte Fragen

Viel Aktivität bedeutet nicht automatisch Fortschritt. Ein Projekt kann an ungeklärten Zuständigkeiten, widersprüchlichen Zielen, fehlenden Voraussetzungen oder aufgeschobenen Entscheidungen stocken. Entscheidend ist, das wirkliche Hindernis zu identifizieren.

Prüfen Sie, welche Ergebnisse tatsächlich entstanden sind, welche Entscheidung oder Voraussetzung fehlt und wer dafür zuständig ist. Gibt es Zielkonflikte zwischen Auftraggeber, Fachbereich und IT? Fehlen Ressourcen oder sind Anforderungen unvereinbar? Mehr Sitzungen, engere Berichte und zusätzliche Aufgaben beheben diese Ursachen nicht von selbst. Benennen Sie die nächste notwendige Entscheidung, die verantwortliche Person und einen Zeitpunkt. Wirkung zählt, nicht nur Aktivität.

Fünf Fragen schaffen Klarheit: Wer entscheidet? Wer bereitet den Entscheid vor? Wer wird vorher einbezogen? Wer wird danach informiert? Was geschieht, wenn keine Einigung zustande kommt?

Entscheidungsbefugnis, fachliche Vorbereitung und Kommunikation sind unterschiedliche Aufgaben. Die Zuständigkeiten müssen vor wichtigen Entscheiden geklärt und mit den erforderlichen Informationen und Befugnissen verbunden werden. Wer entscheidet, muss die Tragweite verstehen und die Verantwortung im Rahmen seiner Rolle übernehmen. Die unternehmerischen Entscheidungen bleiben bei den dafür zuständigen Personen Ihrer Organisation.

Nicht unbedingt. Hinter einem Streit können unterschiedliche Faktenlagen, Annahmen und Interpretationen stehen, aber auch echte Zielkonflikte. Was für den Vertrieb schnell gehen soll, muss für die Qualitätssicherung möglicherweise besonders sicher und für die Geschäftsleitung wirtschaftlich tragbar sein.

Trennen Sie zuerst überprüfbare Fakten, ungeprüfte Annahmen und unterschiedliche Deutungen. Klären Sie anschliessend die legitimen Interessen, Ziele, Risiken und Abhängigkeiten der Beteiligten. Wenn mehrere Ziele nicht gleichzeitig erreichbar sind, genügt mehr Information nicht: Die zuständige Person oder das zuständige Gremium muss bewusst priorisieren und entscheiden. Dokumentieren Sie den Zielkonflikt, die Entscheidung und die Folgen.

Ein gemeinsames IT-Zielbild entsteht, wenn die beteiligten Bereiche ihre Probleme, Bedürfnisse und Prioritäten zuerst gemeinsam klären. Erst danach sollten Lösungen, Geräte oder Anbieter verglichen werden.

Erheben Sie mit Verwaltung, Fachbereichen, IT und gegebenenfalls Schulen die heutige Situation. Trennen Sie Beobachtungen von Wünschen, erfassen Sie Abhängigkeiten und bestimmen Sie gemeinsam, welche Probleme zuerst gelöst werden sollen. Formulieren Sie daraus ein Zielbild mit priorisierten Handlungsfeldern, Verantwortlichkeiten und nächsten Schritten. Hosang Consulting hat einen solchen Weg in einem dokumentierten Mandat für eine öffentliche Organisation begleitet. Ein abgestimmtes Zielbild ist eine Entscheidungsgrundlage, nicht bereits die technische Umsetzung.

Projektarbeit auf Zuruf erreicht ihre Grenzen, wenn Zuständigkeiten unklar werden, Abstimmungen zunehmen, Entscheide liegen bleiben und erfahrene Mitarbeitende ständig eingreifen müssen, damit Vorhaben weiterlaufen.

Kurze informelle Wege sind in kleinen Organisationen oft eine Stärke. Wenn jedoch mehrere Vorhaben und Beteiligte hinzukommen, geht der gemeinsame Überblick leichter verloren. Achten Sie auf wiederholte Rückfragen, nicht abgestimmte Prioritäten, parallele Arbeit und Wissen, das nur einzelne Personen besitzen. Eine fixe Mitarbeiterzahl als Grenze gibt es nicht. Sinnvoll ist eine schlanke gemeinsame Ordnung mit geklärten Rollen, Entscheidungen und wenigen verbindlichen Handlungsprinzipien statt unnötiger Bürokratie.

Gute Improvisation ist wertvoll. Ohne gemeinsame Handlungsprinzipien und nachvollziehbare Dokumentation bleiben gelungene Lösungen aber häufig im «Hosensack» einzelner Personen und lassen sich nur schwer wiederholen oder weiterentwickeln.

Eine Methode muss kein dickes Regelbuch sein. Oft reichen wenige gemeinsam verstandene Grundsätze: Wie klären wir einen Auftrag? Wer entscheidet? Wie lernen wir aus Ergebnissen? Damit wird die Erfahrung Einzelner für andere nutzbar, ohne Eigeninitiative zu unterdrücken. Eine Organisation kann ihren eigenen Ansatz entwickeln. Entscheidend ist, dass er verständlich, weitergebbar und im Alltag hilfreich bleibt.

Prüfen Sie, ob Sie Daten, Dokumentationen und entscheidungsrelevantes Wissen auch ohne Ihren heutigen Anbieter nutzen können. Abhängigkeit zeigt sich besonders dann, wenn ein Wechsel zwar theoretisch möglich ist, praktisch aber Wissen, Schnittstellen oder Handlungsfähigkeit verloren gehen.

Machen Sie einen konkreten Wechseltest: Lassen sich Daten vollständig und in nutzbaren Formaten exportieren? Sind Schnittstellen, Berechtigungen und Entscheidungsregeln dokumentiert? Wer kann auf die Informationen zugreifen, und was geschieht bei einer Preisänderung oder einem Ausfall? Berücksichtigen Sie Verträge, Aufwand und Übergangsrisiken. Digitale Souveränität bedeutet nicht, alles selbst zu entwickeln, sondern Wahlmöglichkeiten und eigene Entscheidungsfähigkeit zu behalten.

Mehr, als es auf den ersten Blick scheint: Solange ein Entscheid aussteht, laufen Kosten weiter, Nutzen verschiebt sich und Optionen können verfallen. Diese Kosten lassen sich grob schätzen, und schon eine grobe Schätzung zeigt, dass Nicht-Entscheiden selbst eine Entscheidung ist.

Ein vertagter Entscheid wirkt kostenlos, weil keine Rechnung dafür eintrifft. Tatsächlich bindet dauerhafte Entscheidungslosigkeit Ressourcen, verwischt Verantwortung und verhindert Lernen. Das Team arbeitet weiter, oft um die offene Frage herum, und erzeugt Aktivität ohne Fortschritt. Für eine grobe Schätzung reichen vier Fragen: Was kostet das Vorhaben pro Woche, solange es auf diesen Entscheid wartet, etwa für Personal, externe Leistungen und Infrastruktur? Welcher Nutzen verschiebt sich mit jeder Woche, zum Beispiel Einsparungen, Umsatz oder die Entlastung einer Fachabteilung? Welche Optionen verfallen zu einem bestimmten Datum, etwa ein Angebot, ein Zeitfenster für die Umstellung oder eine verfügbare Fachperson? Und welche Arbeit muss womöglich wiederholt werden, wenn später anders entschieden wird? Multipliziert mit der realistischen Dauer des Aufschubs ergibt das eine Grössenordnung, keine exakte Zahl. Diese Rechnung ist kein Argument für vorschnelle Entscheide. Je grösser und irreversibler der mögliche Schaden, desto mehr Sorgfalt ist nötig. Sie zwingt aber zu einer ehrlichen Gegenüberstellung: Welche Information gewinnen wir durch Abwarten, und was kostet uns dieses Abwarten? Ist Abwarten richtig, legen Sie ein Datum fest und benennen, welche Information bis dahin vorliegen muss. Eine mögliche Formulierung für die Entscheidungsvorlage: «Bis zum Entscheid laufen pro Woche rund X Franken Aufwand weiter, und der erwartete Nutzen verschiebt sich jeweils um eine Woche. Ab dem [Datum] entfällt die Option Y. Wir empfehlen, bis zum [Datum] zu entscheiden, oder bewusst zu vertagen, unter folgender Bedingung: …»

Indem Sie Unsicherheit offen benennen, die Sorgfalt an der Umkehrbarkeit des Entscheids ausrichten und von Anfang an festlegen, wann und woran der Entscheid überprüft wird. Eine gute Entscheidung ist nicht automatisch eine mit gutem Ausgang, sondern eine, die auf der verfügbaren Grundlage sorgfältig, transparent und verantwortbar getroffen wurde.

Zuerst die Grundlage sortieren: Was ist belegt, was vermutet, was widersprüchlich, was unbekannt? So wird sichtbar, ob weiteres Abklären den Entscheid tatsächlich verändern würde oder ihn nur verzögert. Dann die Sorgfalt nach der Tragweite wählen: Je grösser und irreversibler der mögliche Schaden, desto höher die nötige Sorgfalt. Bei korrigierbaren Entscheiden kann eine Entscheidung auf ausreichender Grundlage besser sein als anhaltendes Zögern. Eine hilfreiche Prüffrage lautet: Würden wir die Entscheidung auch dann noch verantworten, wenn der schlimmste akzeptierte Fall eintritt? Schliesslich den Entscheid korrigierbar machen: Risiken nach Wahrscheinlichkeit und Auswirkung einschätzen, Frühindikatoren und Massnahmen festlegen, Restrisiken und Verantwortliche benennen. Halten Sie Frage und Ziel, bekannte Fakten und offene Annahmen, geprüfte Optionen, Risiken, Gründe und den Zeitpunkt der Überprüfung fest. Dann lässt sich später unterscheiden, ob die Entscheidung schlecht war oder nur ihr Ausgang.

Indem am Ende jeder Phase ausdrücklich zwischen mehreren Optionen gewählt wird, nicht nur zwischen Weitermachen und Abbrechen, und die Wahl auf wenigen Prüffragen beruht. HERMES 2022 sieht dafür Freigabeentscheide des Auftraggebers vor; im Vorgehen von Hosang Consulting kommen fünf Optionen und sieben Prüffragen hinzu.

HERMES 2022 sieht an den Meilensteinen Entscheide des Auftraggebers vor, darunter die Projektinitialisierungsfreigabe, die Durchführungsfreigabe und die Phasenfreigaben. Bei der Durchführungsfreigabe kann der Auftraggeber freigeben, die Freigabe zurückstellen und später erneut beantragen lassen oder das Vorhaben beenden. Ein Phasenübergang ist damit ein Entscheidungspunkt, kein Kalenderdatum. Im Vorgehen von Hosang Consulting unterscheide ich an jedem Übergang fünf Optionen: Go, wenn die Voraussetzungen ausreichen. Adjust, wenn Ziel, Umfang, Rolle, Vorgehen oder Ressourcen angepasst werden. Hold, bis definierte Voraussetzungen erfüllt sind. Stop, wenn das Projekt begründet beendet wird. Handover, wenn die Verantwortung an die Organisation übergeht. Diese Einteilung ist ein eigenes Arbeitsmodell, keine HERMES-Vorgabe. Die Wahl stütze ich auf sieben Prüffragen: Was wissen wir jetzt, was wir vorher nicht wussten? Welche Annahmen wurden bestätigt oder widerlegt? Ist das Ziel weiterhin sinnvoll und erreichbar? Sind Nutzen, Aufwand und Risiko weiterhin vertretbar? Sind Verantwortlichkeiten und Befugnisse klar? Welche Rolle der externen Unterstützung ist jetzt erforderlich, bei interner Leitung: welche Führungsrolle braucht es jetzt? Was muss bis zum nächsten Prüfpunkt beobachtbar sein? Praktisch heisst das: Die Vorlage zum Phasenübergang enthält eine Empfehlung mit einer dieser Optionen, die Antworten auf die Prüffragen und bei Hold die Bedingung, unter der es weitergeht. Ein «Weiter wie bisher» ohne Entscheid ist kein Go, sondern ein ausgebliebener Entscheid.

Nicht jede Zahl in einer Entscheidungsvorlage ist gleich belastbar. Kennzeichnen Sie entscheidungsrelevante Angaben als bekannt, unbekannt, unbestätigt, veraltet, widersprüchlich oder nicht verfügbar und nennen Sie Quelle und Datenstand. Offen benannte Unsicherheit ist eine Information, kein Makel.

Sechs Zustände lassen sich unterscheiden: bekannt (belegt und aktuell), unbekannt (noch nicht erhoben), unbestätigt (eine Vermutung, die geprüft werden muss), veraltet (einmal richtig, seither nicht überprüft), widersprüchlich (Quellen sagen Unterschiedliches) und nicht verfügbar (niemand hat aktuell Zugriff). Wird eine unbestätigte Zahl wie eine Tatsache präsentiert, entsteht eine Entscheidung auf falscher Grundlage, ohne dass es jemandem auffällt. Praktisch: Ergänzen Sie in der Vorlage bei den entscheidenden Angaben eine Spalte «Status» und eine Spalte «Quelle und Stand». Fragen Sie bei den wenigen Zahlen, die den Entscheid tatsächlich tragen: Ist das belegt oder vermutet? Von wann ist es? Würde sich unsere Empfehlung ändern, wenn diese Zahl spürbar daneben liegt? Wo die Antwort ja lautet, lohnt sich zusätzliche Prüfung zuerst. Mehr Daten lösen das Problem nicht automatisch. Nach meiner Einschätzung fallen Entscheide selten wegen fehlenden Willens schwer, sondern weil die Grundlage unklar ist: zu viele Quellen, zu viele Meinungen, zu wenig Klarheit über den tatsächlichen Stand. Ziel ist nicht mehr Daten, sondern ein konsistentes Bild, das offen zeigt, was belegt, vermutet und widersprüchlich ist, und eine Entscheidung, die danach auch getragen wird. Damit jemand «Das wissen wir nicht sicher» in eine Vorlage schreibt, muss das ohne Nachteil möglich sein. Edmondson beschrieb 1999 psychologische Sicherheit als gemeinsame Überzeugung eines Teams, dass es für zwischenmenschliche Risiken sicher ist; in ihrer Feldstudie mit 51 Teams eines Industrieunternehmens hing sie mit Lernverhalten zusammen. Wer Nichtwissen in Vorlagen sehen will, sollte es in Sitzungen deshalb nicht bestrafen. Das gilt nicht nur für Vorlagen: Wer sagt, was er weiss, was er annimmt und was er nicht weiss, macht Entscheide robuster.

Vorbereitung lässt sich delegieren, Entscheidungen, die an der Führungsverantwortung hängen, nicht. Zur Führungsaufgabe gehört dabei auch, dafür zu sorgen, dass das Führungs- und Steuerungswissen, also Vorgehen, Rollen, Entscheidungslogik und gewonnene Erkenntnisse, festgehalten ist und nicht nur in Köpfen liegt.

Mit Führung ist jede Person gemeint, die Verantwortung für gemeinsam erbrachte Ergebnisse trägt, von der Inhaberin bis zur Teamleiterin. Delegierbar sind zum Beispiel ein Variantenvergleich, ein Statusbericht, eine Risikoanalyse oder ein Entwurf des Projektauftrags. Bei der Führung bleiben etwa die Priorität zwischen konkurrierenden Vorhaben, die Freigabe oder der Abbruch eines Vorhabens und die Festlegung von Entscheidungsrechten. Diese Grenze sauber zu ziehen, entlastet und schützt zugleich: Die Führung muss nicht jede Grundlage selbst zusammentragen, und die Mitarbeitenden tragen keine Entscheidungen, für die sie nicht die Befugnis haben. Wie dieser Grundsatz gilt, wenn die Klärung der Projektarbeit an Externe oder eine neue Stelle gehen soll, beantwortet eine eigene Frage. Zur Führungsaufgabe gehört auch, das Risiko von Wissen in Köpfen zu mindern. Festhalten muss die Organisation vor allem ihre Führungs- und Steuerungsinformationen: Vorgehen, Rollen, Entscheidungslogik und gewonnene Erkenntnisse. Fachliche Projektergebnisse können in den dafür vorgesehenen Systemen bleiben. Einen zentralen Ablageort für alle Projektinformationen oder eine unternehmensweite Wissensmanagement-Lösung braucht es dafür nach der Publikation nicht. Eine einfache Kontrollfrage nach jedem wesentlichen Entscheid: Wo ist festgehalten, was wir entschieden haben und warum?

Indem Sie neben dem Ergebnis bewusst die Begründung dokumentieren: Frage und Ziel, bekannte Fakten und offene Annahmen, geprüfte und verworfene Optionen, Risiken, Verantwortliche, Gründe und den Zeitpunkt der Überprüfung. Ein Protokoll zeigt meist, was entschieden wurde, selten warum.

Genau dieser Kontext geht bei Personalwechseln, an Bereichsgrenzen und am Ende einer externen Zusammenarbeit zuerst verloren. Dann wird entweder neu entschieden, ohne die alte Begründung zu kennen, oder ein Entscheid wird falsch fortgeführt, weil die Annahme dahinter nicht mehr sichtbar ist. Wiederkehrende Diskussionen sind häufig ein Hinweis darauf. Hosang Consulting hält wesentliche Entscheidungen nachvollziehbar fest: Frage und Ziel, bekannte Fakten und offene Annahmen, geprüfte Optionen, Risiken, Verantwortliche, Gründe und den Zeitpunkt, an dem die Entscheidung überprüft wird. Ich empfehle, zusätzlich verworfene Optionen, akzeptierte Restrisiken und die Trennung zwischen Vorbereitung und Entscheid festzuhalten und den Vermerk kurz zu halten, damit er tatsächlich geschrieben und gelesen wird. Legen Sie Vermerke dort ab, wo sie unabhängig von einzelnen Personen zugänglich und mit dem betroffenen Vorhaben verknüpft sind, und bestimmen Sie, wer sie pflegt. Kommt eine Diskussion wieder auf, lesen Sie zuerst den Vermerk und fragen: Was wissen wir jetzt, was wir damals nicht wussten? Neue Information rechtfertigt eine Revision; fehlende Kenntnis der alten Begründung nicht.

Oft liegt es nicht an der Strategie, sondern an fehlenden Fähigkeiten der Organisation zwischen Ziel und Umsetzung. Ein weiteres Projekt löst eine solche Lücke selten; es verteilt sie eher auf mehr Beteiligte. Zuerst sollte die konkrete Lücke benannt werden.

Gemeint sind Fähigkeiten der Organisation als System, nicht die Kompetenz einzelner Personen, die oft durchaus vorhanden ist. Hosang Consulting beschreibt fünf typische Lücken: Niemand trägt die Umsetzung über das Projektende hinaus. Wissen hängt zu stark an einzelnen Personen. Entscheide werden getroffen, aber nicht konsequent weitergeführt. Technologie ist vorhanden, aber organisatorisch nicht eingebettet. Und das Tagesgeschäft verdrängt die Veränderung, bis sie still von der Agenda verschwindet. Das ist eine Beobachtung aus der Praxis, keine abschliessende Liste. Fehlen Fähigkeitsbasis und Verantwortung, erzeugen zusätzliche Initiativen nach Einschätzung von Hosang Consulting eher mehr Abstimmung, Belastung, Parallelität und offene Entscheide als mehr Wirkung. Aktivität ist nicht Fortschritt. Prüffragen: Wer trägt die Umsetzung unseres wichtigsten Ziels, namentlich und nicht nur auf dem Papier? Wo hängt Erfolg heute von einer einzelnen Person ab? Welche Entscheidung wurde getroffen, aber nie wirklich umgesetzt? Welche Technologie haben wir eingeführt, ohne die Arbeitsweise anzupassen? Wie viel Kapazität fliesst tatsächlich in die wichtigste Veränderung? Daraus ergibt sich, welche Lücke zuerst zu schliessen ist; erst danach stellt sich die Frage nach Umsetzung oder Technologie.

Erledigte Aufgaben sind noch keine Wirkung. Ein Projekt kann an dem scheitern, was zwischen den Aufgaben liegt: an Entscheidungen, die niemand trifft, an Widersprüchen, die niemand benennt, und an der Wirkung, die nach der Umsetzung niemand mehr prüft.

Aufgabenerfüllung misst den Output: Der Workshop hat stattgefunden, das System ist eingeführt, der Bericht ist geliefert. Ob sich danach etwas verändert, ist der Outcome. Viele Berichte enden beim Output, weil er leichter zu belegen ist. So kann jede Rolle ihren Teil als erledigt melden, während das Vorhaben als Ganzes sein Ziel verfehlt. Nach meiner Erfahrung liegen die Ursachen oft zwischen den Zuständigkeiten: eine widersprüchliche Anforderung, die alle bemerken, aber niemand benennt; eine nötige Entscheidung, die niemand treffen will; eine Eskalation, die als Risiko für die eigene Position gilt. Dann wird rundherum weitergearbeitet. Das Projekt bewegt sich, aber nicht vorwärts. Hilfreich sind drei Prüffragen: Wer verantwortet das Ergebnis des Ganzen, nicht nur die eigenen Teile? Welche Entscheidung wird gerade umgangen statt getroffen? Woran erkennen wir nach der Umsetzung, ob es gewirkt hat, und wer schaut nach?

Behandeln Sie Widerstand zuerst als Information, nicht als Gegner. Er kann auf ungehörte Sorgen, unterschätzte Risiken, unklare Ziele, fehlendes Vertrauen, reale Verluste oder eine noch nicht tragfähige Lösung hinweisen.

Verstehen Sie die Ursache, bevor Sie reagieren. Fragen Sie konkret: «Was genau würde sich für Sie ändern?», «Was befürchten Sie, wenn es so kommt?», «Was müsste anders sein, damit Sie mitgehen können?» Achten Sie dabei auch auf Hinweise, die Ihre Lösung verbessern. Unterscheiden Sie, woher der Widerstand kommt, weil das unterschiedliche Reaktionen verlangt. Hat er nachvollziehbare Gründe, passen Sie die Lösung an. Entsteht er aus Sorge vor der Veränderung, geben Sie Sicherheit und Begleitung, etwa durch klare Informationen, Übergangszeit und feste Ansprechpersonen. Entsteht er aus fehlender Bereitschaft, Fakten zu prüfen und Verantwortung zu übernehmen, benennen Sie Grenzen und Konsequenzen und prüfen Sie die Voraussetzungen des Vorhabens neu. Nachhaltige Veränderung lässt sich nicht erzwingen. Druck kann Verhalten kurzfristig ändern, aber keine innere Bereitschaft ersetzen. Führung darf Klarheit schaffen, Konsequenzen benennen und herausfordern, aber Menschen nicht manipulieren oder ihre Entscheidungsfreiheit umgehen. Wer eine Veränderung ablehnt, trägt die Folgen dieser Entscheidung; machen Sie diese Folgen offen und frühzeitig sichtbar.

Mein Grundsatz lautet: so viel Vertrauen wie möglich, so viel Kontrolle wie aufgrund des Risikos notwendig. Kontrolle soll Risiken beherrschen, nicht fehlendes Vertrauen kaschieren.

Fehlt Vertrauen, entstehen Reibungskosten: mehr Absicherung, mehr Freigabeschleifen, zurückgehaltene Informationen und langsamere Entscheidungen. Umgekehrt ersetzt Vertrauen weder Governance noch notwendige Kontrolle. Vertrauen ohne Verantwortung kann naiv werden, Verantwortung ohne Vertrauen mündet leicht in Mikromanagement. Praktisch können Sie die Kontrolle am Risiko ausrichten: Wie gross und wie umkehrbar ist der mögliche Schaden? Je irreversibler, desto enger die Prüfpunkte, etwa bei Vertragsabschlüssen, Datenmigrationen oder sicherheitsrelevanten Änderungen. Wo Fehler leicht korrigierbar sind, genügen oft klare Ziele, Leitplanken und regelmässige Rückmeldungen statt Einzelfreigaben. Ein Prüfsignal: Wenn eine Freigabe oder ein Bericht kein konkretes Risiko adressiert, sondern vor allem Absicherung schafft, lohnt sich die Frage, welches Vertrauensproblem dahintersteht. Dieses direkt anzusprechen, kann wirksamer sein als eine weitere Kontrollschleife.

Das kann gut funktionieren, solange Sie selbst verfügbar sind. Wird die Abstimmung jedoch dauerhaft von Ihnen abhängig, entsteht ein Engpass. Entscheidungen verzögern sich bei Ihrer Abwesenheit, und wichtiges Wissen bleibt möglicherweise bei Ihnen, statt in der Organisation verfügbar zu werden.

Persönlich einzuspringen kann zunächst richtig sein. Problematisch wird es, wenn daraus ein Dauerzustand wird und keine Verantwortung an andere übergeht. Oft gleicht die Führungsperson dann von Hand aus, was an gemeinsamer Grundlage fehlt, etwa ein verlässlicher Überblick über die laufende Arbeit. Eine einfache Prüffrage: Würden Ihre wichtigsten Vorhaben genauso verlässlich laufen, wenn Sie zwei Wochen nicht erreichbar wären? Wenn nicht, lohnt es sich zu klären, welche Entscheidungen bei wem liegen, welche Informationen alle brauchen und welches Wissen bisher nur bei Ihnen liegt. Eine umsetzungsfähige Organisation ist die, in der niemand mehr alles zusammenhalten muss.

Nach meiner Erfahrung oft an der Steuerung oberhalb der Projektleitung. Wenn niemand mit Zeit und Befugnis rechtzeitig entscheidet, kann auch eine sehr gute Projektleitung das Projekt nicht bewegen, denn die Entscheide der Steuerung bereitet sie vor, trifft sie aber nicht selbst.

In HERMES 2022 ist diese Arbeitsteilung ausdrücklich beschrieben: Der Auftraggeber steuert das Projekt, trägt die Gesamtverantwortung und trifft die Entscheide an den Meilensteinen. Zu seiner Verantwortung gehören rechtzeitige Entscheidungen über Anträge und Massnahmen. Der Projektleiter führt das Projekt im Auftrag des Auftraggebers und hat Entscheidungskompetenz im mit dem Auftraggeber definierten Rahmen. Auch ausserhalb von HERMES gilt dieselbe Logik: Ein Projekt kommt nur so schnell voran, wie die Entscheide fallen, die es braucht. Nach meiner Erfahrung liegt das Problem dann oft eine Stufe höher, beim Auftraggeber. Typische Muster, die ich beobachtet, aber nicht systematisch erhoben habe: Die Person ist als Auftraggeber eingetragen, hat aber keine Zeit oder keine Befugnis. Sie lässt sich informieren, entscheidet aber nicht. Ein Gremium soll gemeinsam entscheiden, und am Ende fühlt sich niemand verantwortlich. Oder ein Lieferant steuert faktisch, weil er das Fachwissen hat. Ein einfacher Test: Führen Sie eine Liste der offenen Entscheide mit dem Datum, an dem sie beantragt wurden. Stehen dort Entscheide seit Wochen, ist nicht die Projektleitung der Engpass. Klären Sie dann mit Namen, wer entscheidet, ob diese Person Zeit hat, an jedem Meilenstein zu entscheiden, und was die Projektleitung selbst entscheiden darf. Eine mögliche Formulierung der Projektleitung gegenüber dem Auftraggeber: «Für die nächsten zwei Wochen brauche ich drei Entscheide von Ihnen. Ohne sie arbeiten wir weiter, aber nicht vorwärts. Bis wann können Sie entscheiden, oder wer soll es an Ihrer Stelle tun?»

Zusätzliche Sitzungen, Werkzeuge oder Mitarbeitende können helfen. Wenn jedoch Prioritäten, Ziele oder Entscheidungsbefugnisse unklar sind, erhöhen sie häufig nur den Koordinationsaufwand. Deshalb prüfe ich zuerst, weshalb ein Vorhaben stockt. Fehlen tatsächlich Kapazitäten, oder verhindern unklare Verantwortlichkeiten und ausstehende Entscheidungen den Fortschritt?

Mehr Sitzungen holen im Gespräch nach, was an gemeinsamer Ordnung fehlt, und unterbrechen dabei die eigentliche Arbeit. In einer Feldbeobachtung von Gloria Mark und Kollegen war die Mehrheit der Arbeitsbereiche von Informationsarbeitenden unterbrochen (57 Prozent). Wurde unterbrochene Arbeit am selben Tag wieder aufgenommen, geschah das im Durchschnitt nach 25 Minuten und 26 Sekunden, dazwischen lagen im Mittel gut zwei andere Arbeitsbereiche. In einem Experiment derselben Forscherin arbeiteten unterbrochene Personen sogar schneller, berichteten aber mehr Stress, Frustration, Zeitdruck und Anstrengung. Ein neues Werkzeug bildet nur ab, was bereits geordnet ist. Zusätzliche Personen können in dieselbe ungeordnete Lage geraten, und mit wachsender Teamgrösse steigt der Abstimmungsaufwand; die bisher Beteiligten können das zudem als Misstrauenssignal lesen. Wer als Führungsperson selbst übernimmt, wird zum Engpass, und das eigene Wissen wird nicht zu geteiltem Wissen. Diese Einschätzungen sind Erfahrung und These, keine Forschungsbefunde. Eine einzige Ursache gibt es nicht: Vorhaben konkurrieren manchmal schlicht um zu wenige Leute, Prioritäten wechseln, Menschen springen zwischen zu vielen Aufgaben. Nach der These der Publikation entsteht der Stau aber oft weiter oben, dort, wo Grundlagen geklärt werden müssten. Bevor Sie Sitzungen, Lizenzen oder Stellen hinzufügen, empfehle ich drei Fragen: Ist entschieden, welches Vorhaben Vorrang hat, und wer darf das entscheiden? Hat jedes Vorhaben ein klares Ziel und einen erkennbaren Beitrag zur Strategie? Ist für alle sichtbar, was gerade läuft und wo es stockt?

Häufige Kontextwechsel sind nicht automatisch ein Problem der Mitarbeitenden. Oft liegen die Ursachen in der Arbeitsorganisation: zu viele parallele Aufgaben, wechselnde Prioritäten oder unklare Entscheidungsbefugnisse. Deshalb untersuche ich zuerst, wie Arbeit geplant, priorisiert und gesteuert wird. Entscheidend ist, ob die Mitarbeitenden ausreichend Zeit und klare Rahmenbedingungen haben, um Aufgaben konzentriert abzuschliessen.

In einem Mandat bei einer wachsenden Digitalagentur lag es nicht am Talent. Das Betriebsmodell war mit den Wachstumsambitionen nicht mitgewachsen: Prioritäten wurden informell gesetzt, Verantwortlichkeiten waren unscharf, und es fehlte ein gemeinsamer Arbeitsrhythmus zwischen Führung, Vertrieb, Delivery und Produktion. Ein Kanban-System machte Prioritäten und laufende Arbeit sichtbar, dazu kamen klarere Sprint-Zyklen und User Stories mit Akzeptanzkriterien. Prioritäten wurden klarer und Kontextwechsel seltener. Das ist ein Einzelfall. Er passt aber zu dem, was die Publikation «Projektmanagement als Organisationsfähigkeit» als Erfahrung und These für wachsende Organisationen beschreibt: Was lange im Zuruf funktioniert hat, trägt irgendwann nicht mehr. Kontextwechsel kosten mehr, als es scheint. In der Feldbeobachtung von Gloria Mark und Kollegen wurde unterbrochene Arbeit, wenn sie am selben Tag wieder aufgenommen wurde, im Durchschnitt erst nach 25 Minuten und 26 Sekunden fortgesetzt, nach gut zwei anderen Arbeitsbereichen dazwischen. In einem Experiment glichen Unterbrochene das durch schnelleres Arbeiten aus, berichteten aber mehr Stress, Frustration, Zeitdruck und Anstrengung. Was Sie prüfen und ändern können: Machen Sie alle laufende Arbeit an einem Ort sichtbar. Steuern Sie ausdrücklich, wie viele Arbeitseinträge gleichzeitig in Arbeit sind; der Kanban Guide verlangt genau diese bewusste Steuerung der laufenden Arbeit (Work in Progress). Legen Sie fest, wo Prioritäten gesetzt und geändert werden und wer das darf. Wenn Sie mit Scrum arbeiten: Nach dem Scrum Guide 2020 ist das Sprint-Ziel die Zusage für das Sprint Backlog; es schafft Fokus und lässt bei der genauen Arbeit Flexibilität. Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden; der Umfang kann mit dem Product Owner geklärt und neu verhandelt werden. Neue Prioritäten gehören deshalb in der Regel ins Product Backlog und damit in die nächste Sprint-Planung. Natürlich kann es auch an fehlenden Fähigkeiten oder zu wenig Kapazität liegen. Diese Frage lässt sich aber erst fair beurteilen, wenn Prioritäten und Arbeitsfluss geklärt sind; sonst bewerten Sie Menschen in einem System, das ständige Unterbrechung erzeugt.

Oft, weil technische Bereitschaft noch keine Steuerung ist. Ein grosser Rollout braucht zusätzlich eine klare Gesamtverantwortung, Gremien, die tatsächlich entscheiden dürfen, Regeln für das Zusammenspiel der Lieferanten, einen Weg, Konflikte aufzulösen, und einen Schutz für den laufenden Betrieb.

Ein Rollout verbindet Technik mit vielen Standorten, Lieferanten, Fachbereichen und dem laufenden Betrieb. Fehlt eine dieser Verbindungen, kann die bereitstehende Technik im Lager oder im Testsystem liegen bleiben. In einem dokumentierten Mandat zur Geräteerneuerung in einem landesweiten Filialnetz war der Rollout unbestritten und die Technik bereit. Frühere Planungsanläufe waren dennoch an der eigenen Komplexität gescheitert: Es fehlten eine klare Programmverantwortung, ein Rahmen für die Lieferantenkoordination und ein Mechanismus, um Konflikte aufzulösen. Prüfen Sie deshalb fünf Punkte: Wer trägt namentlich die Gesamtverantwortung für den Rollout? Gibt es ein regelmässiges Gremium, das entscheiden darf und nicht nur bespricht? Ist geregelt, wer die Schnittstellen zwischen den Lieferanten verantwortet? Wie und bis wann werden Konflikte zwischen Terminplan, Betrieb und Fachbereichen entschieden? Und wie wird verhindert, dass ein Standort während der Umstellung ausfällt? Im genannten Mandat wurde für das verantwortete Teilprojekt eine Steuerung mit klaren Verantwortlichkeiten je Teilstrang, wöchentlichen Entscheidungsgremien mit dem Mandat, Themen zu entscheiden statt nur zu besprechen, Koordinationsregeln für die Lieferanten und einem Schutzkonzept für den laufenden Betrieb aufgebaut. Wenn es an einzelnen Standorten hakt, hilft es, Fehlerbild und Steuerung getrennt anzuschauen: Tritt derselbe Fehler überall auf, liegt die Ursache eher in Paket, Konfiguration oder Vorbereitung. Hängt er davon ab, wer wann informiert, freigegeben oder koordiniert hat, liegt sie eher in der Steuerung. Das ist eine Arbeitshypothese für die Analyse, keine sichere Diagnose.

Zuerst klären, ob es eine neue Information gibt, ob die Person dafür zuständig ist und was die Änderung kostet. Eine begründete Revision ist legitim; schwierig wird es, wenn Entscheide ohne neue Grundlage oder von nicht zuständiger Stelle wieder geöffnet werden. In beiden Fällen gehört die Änderung als neuer, dokumentierter Entscheid mit ihren Folgen auf den Tisch.

Drei Fälle auseinanderhalten: Erstens die berechtigte Revision, weil sich Annahmen als falsch erwiesen haben oder sich die Lage verändert hat. Zweitens ungeklärte Entscheidungsrechte, wenn mehrere Ebenen glauben, über dasselbe zu entscheiden. Drittens ein Ausweichen, wenn ein unbequemer Entscheid formal getroffen, aber nicht getragen wurde. Eine Rücknahme ist nicht automatisch ein Führungsfehler. Im Gespräch mit dem Auftraggeber helfen drei Fragen: «Was wissen wir heute, was wir beim Entscheid nicht wussten?», «Wer ist für diesen Entscheid zuständig?» und «Welche Folgen für Termin, Kosten, Umfang und bereits geleistete Arbeit nehmen wir mit der Änderung in Kauf?» Danach wird die Änderung wie jeder andere Entscheid festgehalten, mit Begründung und Datum. In HERMES 2022 wird eine solche Änderung über das Änderungsmanagement erfasst, bei agilem Vorgehen dann, wenn Ziele, Budget oder Zeitrahmen betroffen sind; über wesentliche Änderungsanträge entscheidet der Auftraggeber und hält seine Entscheide in der Liste Projektentscheide Steuerung fest. Werden Entscheide auf einer anderen Ebene wieder aufgemacht, kann die Ursache in ungeklärten Entscheidungsrechten liegen: Mehrere Rollen haben ein unterschiedliches Bild davon, wer was verantwortet, und Teams erhalten widersprüchliche Vorgaben. Abhilfe schafft ein gemeinsamer Rahmen für Entscheidungsrechte mit einem einfachen Eskalationsmodell für echte Uneinigkeit. Vorbeugen lässt sich mit fünf Fragen vor wesentlichen Entscheiden: Wer entscheidet? Wer bereitet vor? Wer muss vorher gehört werden? Wer wird danach informiert? Was geschieht, wenn keine Einigung erreicht wird? Legen Sie zudem fest, wann ein Entscheid regulär überprüft wird. Dann ist eine Revision ein vorgesehener Schritt und kein Vertrauensbruch.

Indem Sie im Team über die Sache sprechen und mit Einzelnen unter vier Augen über ihr Verhalten. Im Team geht es um Muster, Blockaden und Vereinbarungen, im Einzelgespräch um konkrete Beobachtungen und eine neue, realistische Zusage. Prüfen Sie vorher, ob die Zusage überhaupt einhaltbar war.

Vor dem Gespräch prüfen: War die Zusage klar, mit Termin und Ergebnis? Wurde sie freiwillig gegeben oder vorgegeben? Haben sich Prioritäten, Abhängigkeiten oder Ressourcen seither verändert? Hatte die Person die Mittel und Befugnisse, sie einzuhalten? Eine gebrochene Zusage kann ein Prozessproblem sein und kein Charakterproblem. Unterscheiden Sie zwischen nachvollziehbarem Fehler, fehlendem Wissen, strukturellem Problem, Fahrlässigkeit und bewusster Täuschung. Im Team: Machen Sie den Stand sichtbar, ohne Namen an den Pranger zu stellen, etwa an einem gemeinsamen Board, auf dem Arbeit und Blockaden für alle erkennbar sind. Eine mögliche Formulierung: «Wir haben uns für diese Woche fünf Dinge vorgenommen, drei sind fertig. Was hat die anderen zwei aufgehalten, und was brauchen wir, damit wir das nächste Mal realistischer planen?» Fragen Sie nach Hindernissen, nicht nach Schuldigen. In Scrum ist dafür die Retrospektive vorgesehen, deren Zweck es ist, Wege zur Steigerung von Qualität und Wirksamkeit zu planen. Unter vier Augen, wenn sich bei einer Person ein Muster zeigt: Beschreiben Sie beobachtbares Verhalten und seine Wirkung, fragen Sie nach der Sicht der Person und vereinbaren Sie etwas Konkretes. Beispiel: «In den letzten drei Wochen kamen die Testergebnisse jeweils zwei Tage nach dem vereinbarten Termin. Dadurch musste die Abnahme zweimal verschoben werden. Wie sehen Sie das? Welchen Termin können Sie sicher halten, und woran merken wir früh, wenn es eng wird?» Vereinbaren Sie, dass Verzögerungen früh gemeldet werden: Wer früh sagt, dass eine Zusage wackelt, hat nicht versagt, sondern Steuerung ermöglicht. Vermeiden Sie, Namen und Verfehlungen vor grösserem Publikum aufzuzählen, Vermutungen über Motive zu äussern oder nach privaten oder gesundheitlichen Gründen zu fragen. Spricht die Person persönliche Umstände von sich aus an, nehmen Sie das ernst und verweisen bei Bedarf an die zuständige Linien- oder Personalstelle.

Indem der Status an vorher festgelegte, überprüfbare Kriterien, an Prognosen und an offene Entscheide gebunden wird statt an ein Gefühl, und indem schlechte Nachrichten ohne Nachteil gemeldet werden können. Mehr oder häufigeres Reporting allein löst das nicht, wenn die eigentliche Ursache ein fehlender Entscheid oder fehlende Offenheit ist.

Ein grüner Status trotz Schieflage muss kein Betrug sein. Forschung zu Statusberichten zeigt, dass selektives Berichten vorkommt und Folgen hat: Iacovou, Thompson und Smith (2009) fanden in einer Befragung von 561 Projektleitenden in Informatikprojekten, dass optimistische Färbung die Berichtsqualität verschlechtert, dass höhere Berichtsqualität mit besserer Projektleistung zusammenhängt und dass unter anderem die Macht der vorgesetzten Führungsperson, das Vertrauen der Projektleitung in sie und deren Kommunikationsqualität beeinflussen, ob selektiv berichtet wird. Kriterien statt Farbe: Legen Sie vorher fest, was Grün, Gelb und Rot bedeuten, etwa die Abweichung bei Termin und Kosten gegenüber dem Plan, die Prognose bis Projektende, Zahl und Alter offener Entscheide und kritische Risiken ohne Massnahme. Verlangen Sie eine Prognose, nicht nur einen Ist-Stand: HERMES 2022 sieht vor, dass die Projektleitung Ist und Plan periodisch vergleicht und Prognosen zu Aufwand, Kosten und Terminen erstellt. Kennzeichnen Sie, welche Angaben belegt und welche geschätzt sind. Offene Entscheide gehören in jeden Bericht: Was muss bis wann von wem entschieden werden, und was kostet jede Woche Verzögerung? Nach meiner Erfahrung reagieren Organisationen auf ein stockendes Projekt häufig mit mehr Reporting, engerer Taktung und zusätzlichen Abstimmungsrunden; die Aktivität steigt, die Wirkung nicht. Ein Bericht, der nur Aktivität zeigt, verdeckt, dass irgendwo ein Entscheid fehlt. Schlechte Nachrichten möglich machen: Fragen Sie in der Steuerungssitzung ausdrücklich: «Was macht Ihnen Sorgen, auch wenn es noch nicht im Bericht steht?» Reagieren Sie auf eine Verschlechterung mit Fragen nach Ursache und Unterstützungsbedarf, nicht mit Schuldzuweisung. Ist ein Status seit Wochen grün, während Meilensteine verschoben werden, sprechen Sie den Widerspruch direkt an.

Mit einer gestuften Intervention: zuerst gemeinsame Gesprächsregeln sichtbar machen, dann im Moment das Verhalten ruhig benennen und das Wort zurückgeben, bei Wiederholung ein Gespräch unter vier Augen führen. Sie korrigieren das Verhalten, nicht die Person.

Vorbeugen: Vereinbaren Sie zu Beginn wenige Gesprächsregeln, etwa ausreden lassen, Aussagen kritisieren statt Personen, Annahmen kennzeichnen, nachfragen statt Motive unterstellen. Dann berufen Sie sich bei einer Intervention auf eine gemeinsame Vereinbarung statt auf Ihre Autorität. Auch die Struktur hilft: Runden, in denen alle der Reihe nach sprechen, oder zuerst stilles Notieren und dann Vorstellen. Im Moment: Beim Unterbrechen greifen Sie freundlich und bestimmt ein und geben das Wort zurück: «Moment, [Name] war noch nicht fertig. Bitte zu Ende, danach Sie.» Bei Abwertung benennen Sie die Aussage, nicht die Person, und holen das Gespräch zur Sache zurück: «Halt, so reden wir hier nicht über Vorschläge. Was genau halten Sie daran für falsch?» Bleiben Sie ruhig und kurz; eine Belehrung vor allen beschämt und verschiebt die Aufmerksamkeit vom Thema auf die Auseinandersetzung. Bei Wiederholung unter vier Augen: Beschreiben Sie beobachtbares Verhalten und seine Wirkung, fragen Sie nach der Sicht der Person und vereinbaren Sie etwas Konkretes: «In den letzten zwei Sitzungen haben Sie mehrmals andere unterbrochen und zweimal Vorschläge als naiv bezeichnet. Ich beobachte, dass sich danach weniger Leute äussern. Ihre fachliche Meinung ist mir wichtig, und ich brauche auch die der anderen. Was hilft Ihnen, sie so einzubringen, dass die anderen weiterreden?» Warum sich das lohnt: Wer abgewertet wird oder nicht zu Wort kommt, kann Bedenken und Fehler eher zurückhalten. Edmondson (1999) fand in einer Feldstudie mit 51 Teams, dass psychologische Sicherheit, die gemeinsame Überzeugung, im Team zwischenmenschliche Risiken eingehen zu können, mit Lernverhalten zusammenhing. Woolley und Kollegen (2010) fanden in Laborgruppen, dass ein allgemeiner Faktor der Gruppenleistung über verschiedene Aufgaben unter anderem mit gleichmässiger verteilten Redebeiträgen zusammenhing; ob es diesen Faktor so gibt, ist allerdings methodisch umstritten. Grenze: Wird jemand persönlich angegriffen, bedroht oder diskriminiert, beenden Sie die Situation sofort, notfalls mit einer Pause, und ziehen danach die zuständige Linien- oder Personalstelle bei. Ein offener Austausch schützt Kritik an Aussagen, aber keine persönlichen Angriffe.

Den Bericht nicht beschönigen, aber den Druck ernst nehmen. Trennen Sie, was belegt, was vermutet und was offen ist, und schlagen Sie eine Darstellung vor, die die Lage ehrlich zeigt und zugleich nennt, welche Entscheidung oder Unterstützung jetzt nötig ist.

Wird eine unbestätigte oder geschönte Angabe wie eine Tatsache präsentiert, entscheiden andere auf falscher Grundlage, oft ohne dass es jemandem auffällt, bis es zu spät ist. Eine offen benannte Unsicherheit ist keine Schwäche des Berichts, sondern eine Information. Hinter dem Wunsch steht oft eine verständliche Sorge, etwa um Rückhalt, Budget oder die eigene Position. Fragen Sie nach diesem Motiv. Häufig lässt sich die Sorge auffangen, ohne die Fakten zu ändern, zum Beispiel indem der Bericht neben dem Problem auch die eingeleiteten Massnahmen und die benötigte Entscheidung nennt. Halten Sie Ihre Einschätzung schriftlich und sachlich fest. Bleibt der Druck bestehen, gehört die Frage auf die nächsthöhere Ebene der vereinbarten Projektsteuerung, zum Beispiel an den Auftraggeber oder den Projektausschuss. Relevante Risiken sichtbar zu machen und eine Entscheidung zu verlangen, ist aus meiner Sicht Loyalität gegenüber dem Vorhaben, nicht Illoyalität gegenüber einer Person.

Ein festgefahrenes Projekt sollte nicht allein deshalb fortgeführt werden, weil bereits Zeit und Geld investiert wurden. Ob Abbruch, Pause oder Neuausrichtung sinnvoll ist, hängt vom verbleibenden Nutzen, der Erreichbarkeit der Ziele, den Risiken und realistischen Alternativen ab.

Prüfen Sie zunächst, was sich seit dem Projektstart verändert hat: Sind die ursprünglichen Ziele noch relevant? Welche Ergebnisse sind tatsächlich erreichbar? Was würde eine Fortsetzung kosten, welche Risiken entstehen und welche Alternativen bestehen? Stellen Sie eine Anpassung, eine zeitlich begrenzte Pause und einen geordneten Abbruch gegenüber. Legen Sie fest, wer entscheiden darf, welche Informationen für den Entscheid fehlen und wann er spätestens getroffen wird. Bereits entstandene Kosten sind für sich genommen kein Grund zur Fortführung. Ein begründeter Projektabbruch kann eine verantwortungsvolle Entscheidung sein. Bei HERMES liegt die entsprechende Steuerungsentscheidung beim Auftraggeber.

Hosang Consulting passt zu Organisationen, die vor einer komplexen Aufgabe stehen und nicht nur eine Empfehlung, sondern Klarheit, Verantwortung und Umsetzung benötigen.

Das kann eine strategische Neuausrichtung, eine Transformation, ein gefährdetes Projekt, eine organisatorische Veränderung oder eine anspruchsvolle Verbindung von Menschen, Prozessen und Technologie sein.

Entscheidend ist die Bereitschaft, die Ausgangslage offen zu betrachten, notwendige Entscheidungen zu treffen und an der Umsetzung mitzuwirken. Wo lediglich eine vorgefertigte Lösung bestätigt werden soll, bin ich möglicherweise nicht der richtige Partner.

Vor allem in zwei Situationen: vor einer wichtigen Entscheidung und während einer anspruchsvollen Umsetzung.

Vor einer Entscheidung: Ein Vorhaben, eine Investition oder eine Veränderung hat Konsequenzen, aber Ziele, Anforderungen, Optionen oder Risiken sind noch nicht ausreichend geklärt, eine Entscheidung ist festgefahren oder die Verbindung zwischen Strategie und operativem Alltag fehlt.

Während der Umsetzung: Ein Vorhaben kommt nicht voran, verliert die Richtung oder es fehlen Führung, Entscheidungen und klare Verantwortlichkeiten. Dazu gehören auch Transformationen, personelle Übergänge, organisatorische Spannungen und Vorhaben, bei denen mehrere Fachbereiche und Interessen zusammengeführt werden müssen.

Digitalisierung und KI sind in beiden Situationen häufige Anwendungsfelder. Meine Arbeit beginnt aber nicht bei einer Technologie oder Methode, sondern bei der Frage, was tatsächlich geklärt, entschieden oder umgesetzt werden muss.

Ja. Viele Mandate beginnen mit offenen Fragen, widersprüchlichen Erwartungen oder einem Problem, das noch nicht klar beschrieben werden kann.

In einer solchen Situation schaffe ich zunächst ein gemeinsames Verständnis. Ich untersuche Ziele, Interessen, Abhängigkeiten, Risiken und vorhandene Fähigkeiten. Dabei betrachte ich Menschen, Prozesse und Technologie als zusammenhängendes System.

Erst danach entscheide ich gemeinsam mit Ihnen, welche nächsten Schritte sinnvoll sind. Ich vermeide es, vorschnell eine Lösung oder ein umfangreiches Projekt aufzusetzen, solange die eigentliche Ausgangslage nicht verstanden ist.

Radical Change ist eine eigene Perspektive von Hosang Consulting, kein etabliertes wissenschaftliches Standardmodell. Rapid Change beschreibt darin, wie schnell ein Unternehmen auf Veränderungen reagiert. Radical Change stellt die tiefere Frage, ob die vorhandenen Fähigkeiten überhaupt noch zu dem passen, was eine Organisation morgen erreichen muss.

Klassische Transformation reicht dann nicht mehr aus, wenn viel Aktivität stattfindet, Entscheidungen aber trotzdem lange dauern, Verantwortung über mehrere Rollen verteilt ist, ohne dass sie jemand wirklich trägt, oder ein strukturelles Problem wiederholt mit einem neuen Tool statt mit einer echten Klärung angegangen wird.

Ja, sofern die Beteiligten bereit sind, die tatsächliche Situation offen zu prüfen.

Bei gefährdeten Projekten analysiere ich nicht nur Termine, Kosten und technische Probleme. Häufig liegen wesentliche Ursachen in unklaren Zielen, fehlenden Entscheidungen, widersprüchlichen Interessen, ungeklärten Verantwortlichkeiten oder einer unzureichenden Einbindung der betroffenen Menschen.

Je nach Situation stabilisiere ich das Vorhaben, schaffe Transparenz, kläre die Führungs- und Entscheidungsstruktur oder übernehme operative Projektverantwortung. Eine Fortführung um jeden Preis empfehle ich nicht. Manchmal ist eine Neuausrichtung, Verkleinerung oder geordnete Beendigung die verantwortungsvollere Lösung.

Ich lehne ein Mandat ab, wenn ich keinen realistischen Beitrag leisten kann, die notwendige Kompetenz nicht sicherstellen kann oder Ziele und Erwartungen nicht verantwortbar sind.

Dies gilt auch, wenn lediglich eine bereits getroffene Entscheidung nachträglich legitimiert werden soll, wesentliche Informationen bewusst zurückgehalten werden oder keine Bereitschaft besteht, erkennbare Risiken und Folgen zu betrachten.

Ebenso übernehme ich keine Aufgabe, bei der Vertraulichkeit, Integrität oder ein verantwortungsvoller Umgang mit Menschen und Informationen nicht gewährleistet werden kann. In solchen Fällen spreche ich meine Einschätzung offen aus.

Drei Schritte helfen bei der ersten Einschätzung: Beschreiben Sie, was heute gut funktioniert und was nicht. Entwerfen Sie ein konkretes Zielbild. Leiten Sie daraus die nächsten Entscheidungen, Risiken und Schritte ab. Das ist ein Denkwerkzeug, kein wissenschaftlich validierter Test.

Beginnen Sie wertschätzend: Was soll erhalten bleiben, was könnte besser werden und was hindert das Vorhaben? Fragen Sie anschliessend, wie ein guter Zustand im Alltag konkret aussehen würde. Vergleichen Sie Ausgangslage und Zielbild und bestimmen Sie, was zuerst geklärt werden muss. Ein kurzes Prämortem ergänzt den Blick: Angenommen, das Vorhaben scheitert. Welche Ursachen wären denkbar? Daraus kann auch der bewusste Entscheid entstehen, nichts zu verändern oder intern weiterzuarbeiten. Die ausführliche Anleitung steht in «Ein ehrlicher Blick auf Ihr nächstes Vorhaben».

Wenn die Aufgabe intern genauso gut gelöst werden kann: Das nötige Wissen ist vorhanden, eine geeignete Person erhält wirklich Zeit und Befugnis, und die Beteiligten können die Lage offen besprechen. Externe Unterstützung lohnt sich eher, wenn eine unabhängige Sicht, fehlende Erfahrung oder befristete Kapazität den Unterschied macht.

Ein Sonderfall ist die umgekehrte Lage, in der ohne eine langjährige externe Person nichts mehr entschieden wird; dann fehlt eher Befähigung als Beratung (siehe die Frage nach Beratungs- oder Befähigungsproblem). Vor einem Beizug helfen vier Fragen: Wissen wir, was genau geklärt oder entschieden werden muss? Gibt es intern jemanden mit passender Erfahrung, der dafür tatsächlich Zeit erhält? Können wir unbequeme Befunde intern ansprechen, ohne dass Rollenkonflikte entstehen? Und brauchen wir die Unterstützung nur für eine begrenzte Zeit? Lauten die ersten drei Antworten Ja, spricht vieles dafür, es selbst zu tun; ist nur die Kapazität knapp und befristet, kann gezielte externe Unterstützung genügen. Ziehen Sie extern bei, legen Sie von Beginn an fest, woran Sie das Ende der Unterstützung erkennen (siehe die Frage, wann ein Beratungsmandat enden kann).

Ja. Ich biete eine unabhängige Einschätzung an, welche Veränderungen sinnvoll und realistisch sind, auch für bereits laufende Vorhaben. Wertvoll ist eine Zweitmeinung allerdings nur, wenn Interessen an einer bestimmten Lösung oder an einem Folgeauftrag offengelegt sind und das Ergebnis auch «zurückstellen» oder «nicht weiterverfolgen» lauten darf.

Eine gute Zweitmeinung prüft nicht zuerst die Technik, sondern die Begründung des Vorhabens. Hilfreiche Fragen sind: Welches Problem soll gelöst werden, und sehen die Betroffenen es ebenso? Auf welchen Annahmen beruht der erwartete Nutzen, und sind sie geprüft? Welche Alternativen wurden verglichen, einschliesslich dessen, was mit bestehenden Systemen möglich ist? Welche Kosten entstehen über die Lebensdauer, also auch für Betrieb, Support und Weiterentwicklung? Welche Voraussetzungen müssen erfüllt sein, etwa Kapazitäten, Fähigkeiten und Entscheidungen? Und wie abhängig macht die Lösung von einem Anbieter? Bei einem laufenden Vorhaben kommen drei Fragen dazu: Was wissen wir jetzt, was wir vorher nicht wussten? Ist das Ziel weiterhin sinnvoll und erreichbar? Sind Nutzen, Aufwand und Risiko weiterhin vertretbar? Ein Vorhaben sollte nicht nur deshalb weiterlaufen, weil schon viel investiert wurde. Unabhängigkeit erkennen Sie an einfachen Punkten: Die prüfende Person legt offen, ob sie mit Herstellern, Werkzeugen oder Umsetzungspartnern verbunden ist und ob sie sich für die Umsetzung bewirbt. Sie beurteilt Optionen herstellerunabhängig. Und sie hat vorab bestätigt, dass auch ein Nein, ein Zurückstellen oder die interne Weiterführung ein zulässiges Ergebnis ist. Bei Hosang Consulting beginnt das mit einer kostenlosen Passungsklärung von 20 bis 30 Minuten. Nach dem obigen Massstab gehört auch die eigene Lage auf den Tisch: Hosang Consulting kann nach einer Zweitmeinung auch Projektleitung oder die Organisation der Umsetzung übernehmen und bringt bei Bedarf Fachpersonen oder Umsetzungspartner ein. Das sollten Sie kennen, bevor Sie die Einschätzung bewerten. Ist eine vertiefte Klärung nötig, ist sie der erste bezahlte Schritt, abgerechnet nach Aufwand mit einem vorab vereinbarten Kostendach. Sie erhalten eine Empfehlung; zu einem Folgeauftrag verpflichtet das nicht.

Eine externe Projektleitung ist sinnvoll, wenn intern die Kapazität, die passende Erfahrung oder die nötige Unabhängigkeit fehlt. Die interne Lösung reicht, wenn eine geeignete Person wirklich Zeit für die Aufgabe erhält, Auftrag und Entscheidungswege geklärt sind und das Vorhaben nicht bewusst von aussen geführt werden soll.

Typische Gründe für eine externe Projektleitung sind: Für ein neues Vorhaben fehlen eigene Kapazitäten; die vorhandenen Projektleitenden sind ausgelastet; für eine bestimmte Aufgabe fehlt die passende Erfahrung; ein Vorhaben soll bewusst von einer externen Person geführt werden; der Auftraggeber möchte eine unabhängige Aussensicht; oder ein laufendes Projekt steckt in Schwierigkeiten. Bevor Sie extern vergeben, lohnt sich eine ehrliche Prüfung der internen Lösung mit vier Fragen. Erhält die vorgesehene Person tatsächlich Zeit, oder kommt die Projektleitung zur bisherigen Linienaufgabe einfach dazu? Hat sie schon ein Vorhaben vergleichbarer Komplexität geführt? Ist geklärt, wer Auftraggeber ist und welche Entscheide wo fallen? Und kann sie unbequeme Befunde gegenüber Vorgesetzten und Kollegen ansprechen, ohne in einen Rollenkonflikt zu geraten? Lauten alle vier Antworten Ja, spricht vieles für die interne Lösung, auch weil Wissen und Beziehungen dann im Haus bleiben. Dazwischen gibt es eine dritte Möglichkeit: Nicht jedes Vorhaben braucht eine neue Projektleitung. Externe Unterstützung kann die bestehende Projektleitung begleiten, eine Standortbestimmung machen oder an konkreten, anspruchsvollen Aufgaben mitarbeiten. Führung und Entscheidungen bleiben dann intern. Diese Form passt, wenn die interne Person grundsätzlich geeignet ist, ihr aber für einzelne Punkte Erfahrung oder Zeit fehlt. Was bei der Auslagerung beim Auftraggeber bleiben sollte: die strategischen Ziele, die unternehmerischen Entscheide und die Auftraggeberrolle. Eine externe Projektleitung ist befristet und sollte von Beginn an mit einer geordneten Übergabe geplant werden, damit Entscheidungslogik, Wissen und Dokumentation in der Organisation bleiben. Bei der Auswahl belegt ein Zertifikat geprüfte Erfahrung zu einem bestimmten Zeitpunkt, ersetzt aber nicht die Frage nach vergleichbaren Projekten und nach der Passung zur eigenen Organisation.

Nicht mit einer weiteren Rangliste, sondern mit einem ausdrücklichen Entscheid: Welche Vorhaben laufen weiter, welche werden zurückgestellt und welche beendet, gemessen an ihrem Beitrag und an den Personen, die tatsächlich verfügbar sind. Dafür braucht es eine Stelle, die über alle Vorhaben gemeinsam entscheiden darf.

Erstens: alles auf eine Liste. Erfassen Sie alle laufenden und geplanten Vorhaben, auch kleine und inoffizielle, je mit Ziel, Auftraggeber, beteiligten Schlüsselpersonen und dem nächsten anstehenden Entscheid. Diese Liste kann zeigen, dass mehrere Vorhaben um dieselben wenigen Personen konkurrieren. Dann ist nicht die Zahl der Projekte der Engpass, sondern die Zeit dieser Personen. Zweitens: nach Beitrag beurteilen, nicht nach Lautstärke. Hilfreiche Kriterien sind: Welchen Beitrag leistet das Vorhaben zum Zweck und zum Geschäft der Organisation? Ist es durch Gesetz, Vertrag oder Betriebssicherheit verbindlich? Hängen andere Vorhaben davon ab? Was kostet es, das Vorhaben ein halbes Jahr zu verschieben? Wenn alle Vorhaben die höchste Stufe tragen, ist nichts priorisiert. Drittens: entscheiden statt sortieren. Portfoliomanagement heisst, zu entscheiden, welche Vorhaben gestartet, priorisiert, zurückgestellt oder beendet werden. Ein wirksamer Hebel ist das Zurückstellen: Erst wenn ein Vorhaben ausdrücklich pausiert und das so kommuniziert wird, werden Personen tatsächlich frei. Ein Vorhaben läuft nicht weiter, nur weil schon viel investiert wurde. Viertens: klären, wer entscheidet. Fehlt eine Stelle, die über alle Vorhaben gemeinsam entscheidet, verhandelt jede Projektleitung einzeln um dieselben Leute, und es droht, dass sich durchsetzt, wer am meisten Druck macht. In der Publikation von Hosang Consulting «Projektmanagement als Organisationsfähigkeit» sind das die Klärungsfelder 3 («Welche Vorhaben starten wir, und welche nicht?») und 4 («Wer entscheidet über die Vorhaben?»). In kleinen Organisationen kann diese Stelle die Geschäftsleitung sein. Wichtig ist ein fester Rhythmus, in dem die Prioritäten überprüft werden, etwa bei der Freigabe neuer Vorhaben.

Nicht ab einer bestimmten Unternehmensgrösse. Entscheidend sind Anzahl und Komplexität der Vorhaben, ihre gegenseitigen Abhängigkeiten, die verfügbaren Ressourcen und der tatsächliche Koordinationsbedarf. Auch kleine Organisationen können einen verbindlichen Rahmen benötigen; er sollte so einfach wie möglich und so umfassend wie nötig sein.

Die Organisationsforschung erklärt den Zusammenhang: Je grösser die Unsicherheit einer Aufgabe und je stärker ihre Teile voneinander abhängen, desto mehr Information muss verarbeitet und abgestimmt werden (Galbraith 1974; Burton und Obel 2018). Das PMI empfiehlt entsprechend, Vorgehen und Steuerung an das konkrete Vorhaben, seine Risiken und sein Umfeld anzupassen, statt allen Vorhaben denselben Rahmen vorzugeben. Ein vereinfachtes Rechenmodell zeigt, wie schnell die möglichen Gesprächswege wachsen: Bei n Personen sind es n·(n-1)/2, bei zwanzig Personen also 190. Es zeigt eine Grössenordnung, liefert aber keine empirisch belegte Schwelle, ab der eine gemeinsame Projektordnung nötig wird. Eine grössere Zahl ähnlicher, weitgehend unabhängiger Vorhaben kann weniger Koordination verlangen als wenige komplexe, stark voneinander abhängige Vorhaben. Ich empfehle deshalb, statt der Grösse diese Fragen zu prüfen: Wie viele Vorhaben laufen gleichzeitig? Wie stark hängen sie voneinander ab, etwa über gemeinsame Termine, Systeme oder Ergebnisse? Konkurrieren sie um dieselben Personen oder Mittel? Ist geklärt, wer über Prioritäten, Freigaben und Abbrüche entscheidet? Ist für jedes Vorhaben klar, wer es verantwortet und wer das Ergebnis übernimmt? Sind Statusmeldungen verschiedener Vorhaben vergleichbar? Je mehr dieser Fragen offen sind, desto eher lohnt sich ein gemeinsamer, schlanker Rahmen. Die alltäglichen Warnsignale, an denen sich zeigt, dass Projektarbeit auf Zuruf nicht mehr reicht, beschreibt eine eigene Frage.

Ein sinnvoller Zeitpunkt ist vor der verbindlichen Festlegung von Ziel und Lösung, solange wesentliche Alternativen noch offenstehen. Forschung zu grossen öffentlichen Investitionsvorhaben unterstreicht die Bedeutung dieser frühen Phase. Dass Klärung im Einzelfall Geld spart, bleibt eine begründete Annahme und keine allgemeine Kostengarantie.

Forschung zu grossen öffentlichen Investitionsprojekten in Norwegen weist in dieselbe Richtung: Knut Samset und Gro Holst Volden fanden in der frühen Phase, bevor ein Lösungskonzept gewählt wird, häufig Mängel in Analyse und Entscheidungsprozess, und sie sehen dort ein grosses Verbesserungspotenzial. Die Publikation «Projektmanagement als Organisationsfähigkeit» greift aus dieser Arbeit das Paradox auf, dass Organisationen weniger Mittel in die richtige Grundidee stecken als in bessere Leistung während der Umsetzung. Dass die frühe Klärung trotzdem oft unterbleibt, hat auch mit einem Denkfehler zu tun, den Daniel Kahneman als Innensicht gegen Aussensicht beschreibt: Wer den Aufwand aus dem eigenen Plan heraus schätzt, liegt regelmässig zu tief. Die Referenzklassen-Prognose korrigiert die eigene Schätzung mit dem tatsächlichen Verlauf vergleichbarer Vorhaben. Die Publikation nutzt Kahneman als Denkquelle, nicht als Beleg. Ich empfehle vor einer verbindlichen Freigabe fünf Fragen: Welches Problem soll gelöst werden, und für wen? Woran erkennen wir Erfolg? Welche Alternativen gibt es, einschliesslich «nichts tun»? Wie lange und wie teuer waren vergleichbare Vorhaben tatsächlich? Was wäre der wahrscheinlichste Grund, wenn das Vorhaben in einem Jahr gescheitert wäre? Frühe Klärung heisst nicht, jedes Projekt schwerer zu machen. Es geht darum, die richtigen Fragen zu stellen, solange grundlegende Kurskorrekturen noch vergleichsweise einfach möglich sind.

Das hängt davon ab, wo Ihr Vorhaben steht. Ist der Bedarf noch unklar, hilft Business Analyse; geht es um eine neue Geschäftsmöglichkeit, Business Development; um Veränderungen in Prozessen, Organisation und Systemen, digitale Transformation; ist ein Vorhaben beschlossen, Projektmanagement; und brauchen Führungspersonen eine unabhängige Reflexion oder neue Fähigkeiten, Sparring und Befähigung.

Die wichtigste Prüffrage lautet: Ist die Entscheidung schon getroffen? Solange offen ist, was genau gebraucht, beschafft oder beauftragt werden soll, schafft Business Analyse eine Entscheidungsgrundlage, bevor Zeit, Budget und Ressourcen gebunden werden. Sind Ziel, Anforderungen und Lösung bereits ausreichend geklärt, braucht es keine zusätzliche Analyse um ihrer selbst willen. Steht eine neue Geschäftsmöglichkeit im Raum, prüft Business Development Kundennutzen, Angebot, Markt und wirtschaftliche Tragfähigkeit; ein begründetes Nein kann dabei genauso wertvoll sein wie ein neues Vorhaben. Ist entschieden, was sich verändern soll, verbindet digitale Transformation die Grundlagen mit den nötigen Veränderungen in Prozessen, Systemen, Organisation und Zusammenarbeit. Nicht jede Situation braucht dafür ein grosses Programm; manchmal genügen gezielte Verbesserungen. Projektmanagement führt ein beschlossenes Vorhaben durch die Umsetzung, als Projektleitung auf Zeit oder als Unterstützung der bestehenden Führung, wenn Kapazität, Erfahrung oder eine unabhängige Aussensicht fehlen. Sparring und Befähigung setzen bei Menschen an: wenn im Führungsteam unklar ist, wer was entscheidet, eine wichtige Entscheidung mit einer unabhängigen Person durchdacht werden soll oder ein Team neue Arbeitsweisen übernehmen muss. Das ist Sparring aus Führungs- und Projektpraxis, keine psychologische Beratung. Die Leistungen lassen sich einzeln oder verbunden einsetzen; ein Übergang von der Analyse in die Umsetzung ist möglich, aber kein Automatismus. Wenn Sie unsicher sind, beschreiben Sie zuerst, welche Entscheidung ansteht und wer sie trifft. Daraus ergibt sich oft schon, welche Art von Unterstützung sinnvoll ist.

Nicht mit mehr Tempo, sondern mit einer nüchternen Lageeinschätzung: Ziele, ausstehende Entscheidungen, Verantwortlichkeiten, Abhängigkeiten und Risiken klären und danach bewusst entscheiden, ob das Vorhaben fortgeführt, angepasst oder beendet wird. Bei der Leistung Projektmanagement beginne ich mit einer begrenzten, bezahlten Lageeinschätzung; danach kann eine Projektleitung auf Zeit oder eine Unterstützung der bestehenden Führung folgen. Für die Mitarbeit an den kritischen Punkten eines laufenden Vorhabens gibt es zudem ein eigenes Angebot, das Dorian Ferrari und ich gemeinsam erbringen.

Die Ursachen liegen nach meiner Erfahrung häufig nicht nur bei Terminen, Kosten und Technik; welche weiteren Ursachen ich prüfe, beschreibt die Antwort zur Übernahme festgefahrener oder gefährdeter Projekte. Vier Fragen helfen beim Einstieg: Welche Entscheidung steht aus, und wer muss sie treffen? Wer ist wofür zuständig? Was blockiert was, und was kann warten? Ist das Ziel noch sinnvoll und erreichbar? Bei der Leistung Projektmanagement ist mein Einstieg eine Lageeinschätzung als erster bezahlter Schritt, nach Aufwand mit vorab vereinbartem Kostendach. Das Ergebnis ist eine Empfehlung, ob eine externe Projektleitung, eine unabhängige Unterstützung, die interne Weiterführung oder ein anderer Weg sinnvoll ist. Bei der Mitarbeit im laufenden Vorhaben (Angebot «Institut für angewandtes Projektversagen», gemeinsam mit Dorian Ferrari) setzen wir an sechs Punkten an: Entscheidungen herbeiführen, Festgefahrenes lösen, Stakeholder und Lieferanten mitführen, Governance und Verantwortung klären (wer entscheidet was, bis wann und mit welchen Folgen, schriftlich und kurz), Abhängigkeiten ordnen sowie Wissen und Kontext ins Team übertragen. Der erste bezahlte Schritt heisst dort «Einstieg», ebenfalls nach Aufwand mit Kostendach; die Verantwortung für das Vorhaben bleibt bei Ihnen, und der Einsatz endet mit einer dokumentierten Übergabe. Wie in der Antwort zur Übernahme gefährdeter Projekte gilt: keine Fortführung um jeden Preis. Ich mache Entscheidungsgrundlagen, Risiken und Optionen sichtbar; den Entscheid trifft der Auftraggeber.

Bei der Anwendung von HERMES ja, Methodenschulungen und Zertifizierungsvorbereitung nein. Ich übernehme die Projektleitung oder unterstütze Ihre Projektleitung dabei, HERMES passend einzusetzen.

Konkret geht es um den Zuschnitt der Methode, das Aufsetzen der Projektorganisation und die Entscheide an den Meilensteinen. Ziel ist, dass Ihre Organisation die Methode danach selbst anwenden kann. Ich arbeite seit Jahren mit HERMES, bin seit 2023 IPMA Level C zertifiziert (Certified Project Manager, gültig bis 2028) und seit 2024 im Vorstand des HERMES Connect Hub. Für Kurse und Zertifizierungen gibt es dafür vorgesehene Stellen. HERMES-Zertifikate gibt es in den Stufen Foundation und Advanced; laut Bundeskanzlei liegt der Zertifizierungsprozess bis Ende 2026 bei TÜV SÜD und ab 1. Januar 2027 bei der SAQ. IPMA-Zertifizierungen führt in der Schweiz der VZPM durch. HERMES setze ich dort ein, wo es zur Aufgabe passt; je nach Kontext arbeite ich auch mit klassischen, agilen oder hybriden Vorgehensweisen.

Es kann einem Führungsteam helfen, unterschiedliche Bilder davon zu klären, was das Unternehmen aufbaut und wer welche Entscheidungen verantwortet. Ob das gelingt, hängt von der Situation und der Bereitschaft der Beteiligten ab; eine Wirkungsgarantie gibt es nicht.

In Wachstumsphasen verändern sich Rollen oft schneller, als sie geklärt werden. Anzeichen dafür sind widersprüchliche Vorgaben an die Teams, Prioritäten, die gesetzt und wieder umgestossen werden, und Entscheide, die auf einer anderen Ebene erneut aufgemacht werden. Nach aussen ist das häufig nicht sichtbar, intern erzeugt es Reibung. Ein veröffentlichtes Fallbeispiel von Hosang Consulting zeigt ein mögliches Vorgehen: In einem international tätigen Technologieunternehmen in der Skalierungsphase hatten CEO, CTO und CSO unterschiedliche Bilder davon, was das Unternehmen aufbaut und wer was verantwortet. Ich habe mit den dreien einzeln und gemeinsam gearbeitet, in Einzelgesprächen herausgearbeitet, wo die Bilder auseinanderlaufen, und die bisher vermiedenen Gespräche moderiert. Daraus entstanden ein gemeinsamer Rahmen für Entscheidungsrechte, ein einfaches Eskalationsmodell für echte Uneinigkeit und gemeinsame Arbeitsprinzipien. Laut Fallbeispiel fand das Führungsteam diese Klarheit in drei Monaten. Prüfen Sie vorab: Sind die obersten Verantwortlichen bereit, selbst teilzunehmen, statt die Klärung zu delegieren? Gibt es einen konkreten Anlass, etwa wiederkehrende Konflikte über Zuständigkeiten? Und ist vereinbart, woran Sie nach einigen Monaten eine Verbesserung erkennen, zum Beispiel an weniger erneut aufgemachten Entscheiden?

Die Begriffe sind nicht einheitlich definiert. Vereinfacht: Coaching unterstützt Sie dabei, eigene Lösungen zu entwickeln. Mentoring gibt Erfahrung weiter. Sparring hinterfragt Annahmen und Optionen vor einer Entscheidung. Begleitung im Vorhaben heisst, in einem laufenden Vorhaben mitzuarbeiten und dabei Fähigkeiten im Team aufzubauen.

Coaching: Die International Coaching Federation (ICF) beschreibt Coaching als partnerschaftliche Zusammenarbeit in einem anregenden und kreativen Prozess, der Klientinnen und Klienten dazu inspiriert, ihr persönliches und berufliches Potenzial auszuschöpfen. Bei Hosang Consulting heisst das: Coaching unterstützt Sie dabei, eigene Lösungen zu entwickeln. Mentoring: Eine erfahrene Person gibt Erfahrung aus vergleichbaren Situationen weiter, zum Beispiel aus Führungs- und Projektpraxis. Mentoring passt, wenn Ihnen nicht die Klarheit fehlt, sondern Erfahrung damit, wie sich etwas in der Praxis bewährt. Sparring: Ein kritisches Gegenüber bereitet mit Ihnen eine Entscheidung vor, hinterfragt Annahmen und Optionen und widerspricht, wo es nötig ist. Bei Hosang Consulting fragt Sparring nicht zuerst, wie sich etwas anfühlt, sondern was Sie jetzt konkret ändern. Begleitung im Vorhaben: Die begleitende Person arbeitet in einem laufenden Vorhaben mit und baut dabei Fähigkeiten im Team auf, mit dem Ziel, dass das Team danach eigenständig weiterarbeitet. Befähigung kann allgemein eine Führungsperson, ein Team oder die Organisation betreffen, etwa wenn Entscheidungsrechte, Eskalation und Wissen festgehalten werden sollen. Für die Wahl hilft die Frage, was Ihnen gerade fehlt: eigene Klarheit (Coaching), Erfahrung (Mentoring), ein kritisches Gegenüber für eine konkrete Entscheidung (Sparring) oder Kapazität und Können im Team (Begleitung). Mischformen sind möglich. Keine dieser Formen ist psychologische Beratung oder Therapie; bei persönlichen Belastungen gehört die Unterstützung zu entsprechend ausgebildeten Fachpersonen.

Seit meinem 50. Lebensjahr verfolge ich das Ziel, einen erheblichen Teil meiner Zeit in ausgewählte nicht-kommerzielle Aufgaben zu investieren. Das ist keine mathematische Quote und kein Gratisangebot, sondern Zeit, die bewusst dort eingesetzt wird, wo Verantwortung übernommen wird und Wirkung entstehen kann.

Mehr dazu und die aktuellen Engagements finden Sie unter /engagement.

Nein. Wo ich Zeit und Erfahrung investiere, erwarte ich Verbindlichkeit, Pünktlichkeit, aktive Mitarbeit und die Bereitschaft, Verantwortung zu übernehmen und Veränderung wirklich anzugehen.

Nicht jedes Anliegen passt – und nicht jede gute Idee braucht Beratung. Im Gespräch lässt sich meist schnell klären, ob meine Erfahrung an der richtigen Stelle Wirkung entfalten kann.

Ich setze diese Zeit dort ein, wo Menschen bereit sind, Verantwortung zu übernehmen und Veränderung wirklich anzugehen, und wo meine Erfahrung Wirkung entfalten kann. Ob ein Anliegen passt, klären wir in einem Gespräch, das über die Seite «Engagement» gebucht werden kann.

Die Engagements bewegen sich in vier Themenfeldern: Bildung & Entwicklung, Orientierung & Berufung, Gesellschaft & Verantwortung sowie Befähigung & Unternehmertum. Beispiele sind die FamilyLounge Chur, die landwirtschaftliche Befähigung in Kenia, die Bildungsinitiative «Graubünden liest» und das Engagement im Stadtpark Chur. Wie Verbindlichkeit und Passung verstanden werden, beschreiben die Fragen «Bedeutet ein nicht-kommerzielles Engagement weniger Verbindlichkeit?» und «Wie lässt sich klären, ob ein Engagement passt?». Für ein erstes Gespräch hilft eine kurze Beschreibung: worum es geht, wer die Verantwortung trägt und was sich konkret verändern soll.

Verstehen bedeutet, die Ausgangslage nicht auf sichtbare Symptome zu reduzieren. Ich betrachte Ziele, Menschen, Prozesse, Technologie, Interessen und Rahmenbedingungen gemeinsam mit Ihnen.

Verantwortung bedeutet, nicht bei Analysen und Empfehlungen stehen zu bleiben. Ich vertrete meine Einschätzung klar, begleite Entscheidungen und übernehme je nach Mandat auch Führungs-, Projekt- oder Umsetzungsverantwortung.

Wirkung bedeutet, dass eine Veränderung nicht nur beschlossen oder technisch eingeführt wird. Sie muss im Arbeitsalltag funktionieren, von den Beteiligten getragen werden und der Organisation einen erkennbaren Nutzen bringen.

Bei Hosang Consulting arbeiten Kunden direkt mit den Personen, die das Mandat verstehen, führen und verantworten. Es gibt keine Übergabe an ständig wechselnde Beratungsteams.

Ich verbinde strategische Klärung mit Business Analyse, Projekt- und Transformationsleitung sowie operativer Umsetzung. Abhängig von der Situation agiere ich als Challenger, Accelerator, Executor oder Observer.

Ich spreche Risiken und fehlende Voraussetzungen offen an. Gleichzeitig ist mein Ziel nicht, eine dauerhafte Abhängigkeit aufzubauen. Wissen, Verantwortung und Fähigkeiten sollen in der Organisation verankert werden.

Ja. Die direkte und persönliche Zusammenarbeit ist ein wesentlicher Bestandteil meiner Arbeitsweise. Kunden werden nicht nach dem Verkaufsgespräch an ein wechselndes Team übergeben.

Für Mandate von Hosang Consulting übernehme ich die Gesamtverantwortung. Je nach Auftrag arbeiten spezialisierte Geschäftspartner eigenständig in ihren vereinbarten Verantwortungsbereichen. Bei HR- und Recruiting-Themen arbeite ich mit Elizabeth Kunhimon zusammen, bei externer Unterstützung im Projektmanagement mit einem erfahrenen Geschäftspartner. Die Mandate des Instituts für angewandtes Projektversagen führe ich gemeinsam mit Dorian Ferrari.

Wenn zusätzliche Fachkompetenz erforderlich ist, beziehe ich geeignete Personen aus meinem Netzwerk ein. Die Verantwortung für die Auswahl, Koordination und Qualität bleibt bei Hosang Consulting.

Business Analyse schafft Klarheit über Bedarf, Anforderungen und Lösungsraum – Ziele, Interessen und Abhängigkeiten, bevor eine Lösung feststeht.

Projektmanagement schafft den organisatorischen Rahmen, plant und steuert die Umsetzung und sorgt dafür, dass Entscheidungen, Risiken und Abhängigkeiten bearbeitet werden. Je nach Kontext arbeite ich mit HERMES, klassischen, agilen oder hybriden Vorgehensweisen; HERMES selbst unterstützt dabei unterschiedliche Umsetzungsformen. In der Praxis greifen beide Rollen ineinander, statt strikt getrennt zu bleiben.

Ich übernehme beides.

Ein Mandat kann mit einer Lageeinschätzung, einer Klärung vor einer wichtigen Entscheidung oder einem Sparring beginnen. Wenn die Situation es verlangt, übernehme ich anschliessend auch Projektleitung, Transformationsleitung oder konkrete Umsetzungsaufgaben, jeweils befristet.

Welche Rolle sinnvoll ist, wird zu Beginn geklärt und im Verlauf regelmässig überprüft. Mein Anspruch ist nicht, möglichst viel Verantwortung zu übernehmen, sondern diejenige Verantwortung, die für das Vorhaben notwendig und für die Organisation tragfähig ist.

Governance ist der verbindliche Rahmen, in dem eine Organisation entscheidet, Verantwortung verteilt und kontrolliert. Für Projekte heisst das vor allem: Wer darf ein Vorhaben genehmigen, verändern oder stoppen, wer redet mit, wer wird informiert, und wie wird eskaliert?

Zur Projekt-Governance gehören Rollen, Entscheidungsrechte, Freigaben und Eskalationswege. Sie ist zu unterscheiden von der Führung eines einzelnen Vorhabens (wie wird es geplant und gesteuert?) und vom Portfolio (welche Vorhaben starten überhaupt?). Im Modell der acht Klärungsfelder von Hosang Consulting ist Governance das vierte Feld. Ohne geklärte Entscheidungsrechte entsteht eine typische Reibung: Jeder wartet auf jeden, und niemand traut sich zu entscheiden. Die Publikation «Projektmanagement als Organisationsfähigkeit» hält als Erfahrung und These fest, dass die Frage, wer eigentlich entscheidet, für Erfolg oder Scheitern oft wichtiger ist als jeder noch so gute Plan. Praktisch empfehle ich, je Vorhaben schriftlich festzuhalten: wer den Auftrag freigibt, wer Umfang, Termine und Budget in welchem Rahmen ändern darf, wer das Vorhaben stoppen darf, wer vorher anzuhören und wer nachher zu informieren ist, und an wen bei fehlender Einigung eskaliert wird. Das passt bei kleinen Vorhaben auf eine Seite. Governance heisst nicht mehr Bürokratie. Ein klarer Rahmen kann Entscheidungen beschleunigen, weil weniger nachgefragt, abgesichert und neu verhandelt werden muss.

Management-Meilensteine sind Entscheidungspunkte, an denen die Führung prüft, ob die Voraussetzungen für den nächsten Schritt gegeben sind und das Vorhaben weiterhin getragen wird. Interne Meilensteine wie das Ende eines Tests oder Sprints liegen dagegen in der Projektabwicklung. Wer an welchem Punkt entscheidet, regeln Auftrag und Governance der Organisation.

Im Referenzmodell von Hosang Consulting führt der Weg vom Projektimpuls über Initialisierung, Konzeption, Realisierung und Einführung bis zur Nutzung. Bei internen Veränderungsprojekten reicht der Führungsbogen bis in die Nutzung, bei Kundenprojekten bis zur verlässlichen Übergabe. Dazwischen liegen fünf Management-Meilensteine: Aufnahme zur Klärung, Auftragsfreigabe, Realisierungsentscheid, Einführungsentscheid sowie Abnahme und Wirkung. Wer entscheidet, beschreibt das Modell über fünf Verantwortungsebenen: Strategie (Grundsatz- und Richtungsentscheide), Portfolio (Entscheide über Vorhaben und Prioritäten im zugewiesenen Rahmen), Steuerung (Projektfreigaben und wesentliche Anpassungen gemäss Mandat), Führung (operative Projektentscheide im delegierten Rahmen) und Abwicklung (Fachentscheide im Arbeitsauftrag). Eine Ebene ist keine Person; ein Steuerungsausschuss oder eine Auftraggeberin kann sie wahrnehmen. Die Projektlandkarte ordnet als Orientierung zu: Über die Aufnahme zur Klärung entscheidet das Portfolio. Auftragsfreigabe, Realisierungs- und Einführungsentscheid trifft die Steuerung; bei der Auftragsfreigabe bestätigt das Portfolio Priorität und Mittel, beim Einführungsentscheid bestätigt die empfangende Organisation ihre Bereitschaft. Über Abnahme und Wirkung entscheidet die Steuerung gemeinsam mit der empfangenden oder nutzenden Organisation. Bei den ersten vier Meilensteinen lauten die möglichen Ausgänge sinngemäss freigeben, nacharbeiten, zurückstellen oder beenden beziehungsweise verwerfen; bei Abnahme und Wirkung etwa abnehmen, mit Auflagen abnehmen, Massnahmen verlangen oder den Nutzen neu beurteilen. Der letzte Punkt ist bewusst gesetzt: Bei internen Vorhaben wird nicht nur gefragt, ob ein Ergebnis eingeführt wurde, sondern ob es im Betrieb trägt und den erwarteten Nutzen entfaltet. Dafür sind die Kennzahlen der Linie massgebend.

Eine Person. HERMES verlangt, dass der Auftraggeber eine einzige natürliche Person aus der Stammorganisation ist, angesiedelt beim Anwender. Ein Gremium kann über einen Projektausschuss einbezogen werden, ersetzt die Rolle aber nicht.

Laut Referenzhandbuch initialisiert, finanziert und steuert der Auftraggeber das gesamte Vorhaben und trägt die Gesamtverantwortung für das Vorhaben und das Erreichen der Ziele. Er muss beim Anwender angesiedelt sein, das Projekt in der Führung der Stammorganisation vertreten und hierarchisch entsprechend hoch angesiedelt sein. Auftraggeber und Projektleiter dürfen nicht dieselbe Person sein. Wo eine Geschäftsleitung, ein Gemeinderat oder eine Kommission mitwirken soll, sieht HERMES den Projektausschuss vor: Der Auftraggeber bestimmt dessen Mitglieder, führt ihn und legt das Stimmrecht fest. So bleibt eine Person verantwortlich, und die relevanten Organisationen sind trotzdem vertreten. Ich empfehle, den Auftraggeber mit Namen zu benennen, nicht nur mit Funktion. Das Muster, dass ein Gremium gemeinsam entscheiden soll und sich am Ende niemand verantwortlich fühlt, habe ich in der Praxis beobachtet, aber nicht systematisch erhoben. Wichtig ist ausserdem, dass die gewählte Person Zeit und Befugnis hat, an jedem Meilenstein zu entscheiden. Zu ihren Kompetenzen gehören laut Referenzhandbuch die Entscheidungskompetenz im Rahmen der Kompetenzordnung der Stammorganisation und die Eskalation an die Stammorganisation. Ist in Ihrer Organisation formell eine Behörde oder ein Gremium zuständig, etwa für Kredite, schliesst das eine Person als HERMES-Auftraggeber nicht aus. Ich empfehle, ihre Kompetenzen schriftlich festzuhalten: Sie handelt im Rahmen der Beschlüsse, die das Gremium gefasst hat, und legt ihm Entscheide vor, die darüber hinausgehen.

Nicht mit der Idee selbst. Ein Projektimpuls, etwa ein Problem, eine Chance oder eine Kundenanforderung, ist noch kein Auftrag. Zuerst wird entschieden, ob er als mögliches Vorhaben überhaupt geprüft wird. Im Referenzmodell von Hosang Consulting wird er erst mit einer bewussten Auftragsfreigabe zum Projekt; viele Methoden kennen einen vergleichbaren Freigabeschritt.

Ein Projektimpuls kann eine Idee, ein Problem, eine Chance, eine Kundenanforderung, eine strategische Initiative oder eine notwendige Veränderung sein. Im Referenzmodell von Hosang Consulting folgen darauf zwei bewusste Schritte: Bei der «Aufnahme zur Klärung» entscheidet das Portfolio, ob der Impuls weiter geprüft wird. In der Initialisierung werden dann Ziele, Nutzen, Auftrag, Mittel, Risiken, Rahmen und Entscheidungskreise geklärt, bis die Steuerung bei der «Auftragsfreigabe» entscheidet. Für die Aufnahme genügt ein knapper Projektsteckbrief. Die Projektlandkarte nennt als Mindestinhalt: Kurzbeschreibung, Ziele und Nutzen, Umfang und Lieferobjekte, Varianten, Ecktermine, Ressourcen, Annahmen und Risiken. Der Projektauftrag für die Freigabe enthält mindestens Ausgangslage, Ziele, Lieferobjekte, Abgrenzung, Planung, Finanzierung, Meilensteine, Organisation, Ressourcen, Risiken, Abhängigkeiten und Freigaben. Der bewusste Schritt lohnt sich, weil Klärung am Anfang in aller Regel am günstigsten ist (Erfahrung und These). Ohne ihn starten Vorhaben nebenbei, und niemand hat entschieden, dass sie Mittel binden dürfen. Ein legitimes Ergebnis ist auch, einen Impuls zurückzustellen oder zu verwerfen. Die Projektlandkarte nennt bei der Aufnahme ausdrücklich die Ausgänge zulassen, nacharbeiten, zurückstellen oder verwerfen.

In HERMES übernimmt bei agilem Vorgehen grundsätzlich der Anwendervertreter zusätzlich die Verantwortung des Product Owners. Der HERMES-Leitfaden Agilität sieht jedoch auch eine getrennte Besetzung vor, insbesondere bei komplexeren Vorhaben.

Entscheidend ist nicht allein die organisatorische Zuordnung. Der Product Owner muss die fachlichen Anforderungen verstehen, Prioritäten setzen und die Verantwortung für den Produktwert wahrnehmen können. Dafür benötigt er ausreichende Entscheidungsbefugnisse und, nach meiner Erfahrung, auch Zeit. Ob beide Rollen von einer Person oder von unterschiedlichen Personen wahrgenommen werden, sollte deshalb bewusst anhand der Projektorganisation und der tatsächlichen Anforderungen entschieden werden.

Der Auftraggeber trägt in HERMES die Verantwortung für die übergeordnete Steuerung des Projekts. Er trifft insbesondere die ihm zugewiesenen Entscheide an den Meilensteinen, etwa zur Freigabe der Projektinitialisierung, zur Durchführung, zu Phasenübergängen sowie zum Projektabschluss oder Projektabbruch.

Bei agilen Vorhaben können zusätzlich Entscheide zu Releases erforderlich sein, soweit diese im Projekt entsprechend vorgesehen sind. Wesentliche Änderungen an Projektzielen, Budget oder Zeitrahmen müssen durch die zuständige Entscheidungsebene beurteilt und freigegeben werden. Der Projektleiter bereitet solche Entscheide vor und verantwortet die operative Projektführung innerhalb seiner Befugnisse. Welche Entscheidungen der Auftraggeber selbst treffen darf, richtet sich nach der Projektorganisation und den geltenden Kompetenzregelungen. Insbesondere bei Beschaffungen und finanziellen Verpflichtungen können weitere zuständige Stellen der Stammorganisation beteiligt sein.

Business Analyse untersucht die Bedürfnisse einer Organisation, klärt Probleme und Ziele und erarbeitet die Grundlagen für wirksame Lösungen. Dabei geht es nicht nur darum, Anforderungen aufzunehmen, sondern auch darum, zu verstehen, weshalb eine Veränderung notwendig ist und welchen Nutzen sie bringen soll.

Requirements Engineering konzentriert sich auf die systematische Ermittlung, Beschreibung, Prüfung und Verwaltung von Anforderungen. Es ist damit ein wichtiger Bestandteil der Business Analyse, kann aber auch in anderen Zusammenhängen eingesetzt werden. Der Product Owner trägt in Scrum die Verantwortung dafür, den Wert des Produkts zu maximieren und das Product Backlog wirksam zu verwalten. Er entscheidet über die Priorisierung der Anforderungen im Product Backlog. In der Praxis ergänzen sich diese Aufgaben. Ein Business Analyst kann den Product Owner fachlich unterstützen, beispielsweise bei der Klärung von Bedürfnissen, der Analyse von Lösungsoptionen oder der Ausarbeitung von Anforderungen. Die Verantwortung des Product Owners bleibt dabei bestehen.

Mindestens: wer namentlich Auftraggeber ist, ob diese Person Zeit und Befugnis für die Entscheide an den Meilensteinen hat, welcher Nutzen bis wann erreicht sein soll, was die Projektleitung selbst entscheiden darf und wer die Anwender mit welchen Befugnissen vertritt.

Diese fünf Fragen sind meine Empfehlung. Sie leiten sich aus Mustern ab, die ich in der Praxis beobachtet, aber nicht systematisch erhoben habe: Auftraggeber ohne Zeit oder Befugnis, Auftraggeber, die sich informieren lassen, aber nicht entscheiden, ein Gremium statt einer Person und ein Lieferant, der das Projekt faktisch steuert, weil er das Fachwissen hat. Über die Häufigkeit dieser Muster ist damit nichts gesagt. Die Fragen lassen sich an HERMES festmachen. Der Auftraggeber muss eine einzige natürliche Person beim Anwender sein; er bestimmt den Projektleiter, legt dessen Kompetenzen fest und bestimmt den Anwendervertreter. Auch Projektleiter und Anwendervertreter müssen beim Anwender angesiedelt sein; auf einen Projektleiter, den Ersteller oder Betreiber stellen, ist wegen möglicher Interessenkonflikte zu verzichten. HERMES legt die Steuerung damit klar auf die Seite der Organisation, die das Ergebnis später nutzt. Halten Sie die Antworten schriftlich fest: zuerst im Projektinitialisierungsauftrag, später im Durchführungsauftrag, auf dessen Grundlage der Auftraggeber die Durchführungsfreigabe trifft. Ein möglicher Gesprächseinstieg: «Bevor wir starten, möchte ich mit Ihnen klären, welche Entscheide Sie selbst treffen, welche Sie mir übertragen und woran wir erkennen, dass sich das Projekt gelohnt hat.» Lässt sich eine der Fragen nicht klären, ist das selbst ein Befund. Fehlt etwa eine Person mit Zeit und Befugnis, sollte das vor der Durchführungsfreigabe offen angesprochen werden und nicht erst, wenn Entscheide liegen bleiben.

Prüfen Sie getrennt: nachgewiesene Führungskompetenz, passende Methodenkenntnis, Erfahrung mit vergleichbarer Komplexität und die Passung zu Ihrer Organisation. Zertifikate wie IPMA ab Level C helfen bei der ersten Frage; die übrigen klären Sie über Referenzen und ein Gespräch über konkrete Situationen.

Ein IPMA-Zertifikat ab Level C ist ein unabhängiger Nachweis, dass Erfahrung geprüft und das eigene Handeln in Bericht und Interview beurteilt wurde. Es belegt aber weder Branchenwissen noch die Kenntnis einer bestimmten Methode, und es ist eine Momentaufnahme. Soll Ihr Vorhaben nach HERMES laufen, prüfen Sie HERMES-Kenntnisse zusätzlich. HERMES verlangt zudem, dass die Projektleitung beim Anwender angesiedelt ist und ausschliesslich dessen Interessen vertritt, auch wenn sie extern rekrutiert wurde; eine Projektleitung, die der Lieferant oder Betreiber stellt, ist wegen möglicher Interessenkonflikte zu vermeiden. Für das Auswahlgespräch empfehle ich Fragen nach konkreten Situationen, dem eigenen Vorgehen und dem Ergebnis, zum Beispiel: Beschreiben Sie ein Projekt, in dem ein wichtiger Entscheid ausblieb; was haben Sie getan, und was war das Ergebnis? Wann haben Sie einem Auftraggeber empfohlen, ein Projekt zu stoppen oder neu auszurichten? Wie sind Sie mit einem Konflikt zwischen Fachbereich und Lieferant umgegangen? Wie sorgen Sie dafür, dass unsere Organisation nach Ihrem Einsatz selbst weiterarbeiten kann? Achten Sie auf konkrete Beispiele mit nachvollziehbarem Ergebnis, auch wenn es nicht nur positiv war; allgemeine Aussagen wie «ich kommuniziere offen» sagen wenig. Sprechen Sie mit früheren Auftraggebern aus ähnlichen Vorhaben, und fragen Sie, welche Projekte seit der letzten Zertifizierung dazugekommen sind. Die Gültigkeit eines IPMA-Zertifikats können Sie über das Datum der letzten (Re-)Zertifizierung einordnen. Klären Sie vor dem Start die Rollen: Die externe Projektleitung führt operativ; Auftraggeberrolle, strategische Ziele und unternehmerische Entscheide bleiben bei Ihnen. Halten Sie schriftlich fest, was die Projektleitung selbst entscheiden darf; in HERMES legt der Auftraggeber die Kompetenzen des Projektleiters fest.

Sie als Auftraggeberorganisation; in HERMES konkret die Rolle Anwendervertreter, also die Seite, die die Lösung nutzt. Nur Sie können entscheiden, was gebraucht wird und was es wert ist. Der Anbieter antwortet mit einem Angebot und zeigt, wie er Ihre Anforderungen erfüllen will.

HERMES ordnet die Verantwortung für die Lösungsanforderungen und für das Erarbeiten der Ausschreibung der Rolle Anwendervertreter zu, also der Seite der Organisation, die die Lösung später nutzt. Die Lösungsanforderungen sollen lösungsneutral formuliert und priorisiert sein und fliessen bei einer Beschaffung in das Lastenheft ein. Die Ausarbeitung können Sie teilen: Fachbereiche bringen ihre Abläufe ein, die Informatik die technischen Rahmenbedingungen, eine Business Analyse führt die Sichtweisen zusammen und formuliert die Anforderungen. Wer mitschreibt, übernimmt damit nicht die Verantwortung für den Bedarf und den Entscheid. Ein Warnsignal ist, wenn die Funktionsliste aus einer Produktbroschüre zum Anforderungsdokument wird. Dann beschreibt der Anbieter Ihr Problem in der Sprache seines Produkts, und Angebote lassen sich kaum noch vergleichen. Beschreiben Sie zuerst Ihre Abläufe und Ziele; ob eine Standardsoftware sie abdeckt, prüfen Sie danach.

Ordnen Sie Analyse, Vorbereitung, Freigabe und Verantwortung getrennt zu: KI kann strukturieren, Varianten vorbereiten und Risiken sichtbar machen, Menschen setzen Prioritäten, wägen Zielkonflikte ab und verantworten die Folgen. Das braucht nicht weniger, sondern präzisere Führung.

Ein einfaches Raster: Legen Sie für jede wiederkehrende Aufgabe im Projekt, etwa Protokoll, Statusbericht, Risikoliste, Anforderungsentwurf oder Mitteilung an Beteiligte, fest, wer analysiert, wer vorbereitet, wer freigibt und wer verantwortet. KI kann bei Analyse und Vorbereitung viel übernehmen. Freigabe und Verantwortung bleiben bei benannten Menschen. Digitale Mitarbeitende dürfen innerhalb eines klar definierten Mandats auch Kommunikation ausführen; Entscheidungen bleiben ausserhalb ihres Mandats. Führung verschiebt sich dabei von direkter Einzelsteuerung zur Gestaltung von Regeln, Rollen und einer gemeinsamen Informationsbasis. Konkret heisst das: ein Mandat je Agent, Eskalationsregeln für den Fall, dass ein Mensch eingreifen muss, bevor etwas nach aussen geht, eine aktuelle gemeinsame Projektinformation und Nachvollziehbarkeit, auf welcher Grundlage etwas erstellt wurde. Diese Ordnung entsteht nicht von selbst. Sie muss festgelegt und im Alltag eingeübt werden; sonst entstehen Reibung, Doppelarbeit und unklare Verantwortlichkeit. Eine brauchbare Prüffrage lautet: Kann jede Person im Team für ein beliebiges KI-gestütztes Ergebnis sagen, wer es freigegeben hat?

Die Ursache liegt nicht zwingend bei den Personen. Prüfen Sie, ob Aufgabe und Verantwortung geklärt waren, ob neue Mitarbeitende tatsächlich eingebunden wurden und ob im Team offener Widerspruch möglich ist. Diese Ursachen können Sie selbst beeinflussen.

Frühe Abgänge haben viele mögliche Gründe, auch solche ausserhalb Ihres Einflusses, etwa private Veränderungen oder ein besseres Angebot. Eine pauschale Antwort gibt es deshalb nicht. Ich vertrete aber die These, dass wiederholte frühe Abgänge selten nur an der Auswahl liegen: Oft wurde nie geklärt, welche Aufgabe gelöst werden soll, welche Verantwortung dazugehört und ob die Organisation bereit ist, die neue Person wirklich einzubinden. Ein Onboarding kann auf dem Papier vollständig sein und trotzdem keine echte Einbindung schaffen, etwa wenn neue Mitarbeitende Informationen spät erhalten, an Entscheidungen nicht beteiligt werden oder ihre Fragen als Störung erleben. Ob jemand wirksam wird, hängt stark davon ab, ob die Zusammenarbeit ehrlichen Austausch ermöglicht. Prüfen Sie konkret: Entsprach die tatsächliche Aufgabe der ausgeschriebenen? Wusste die neue Person nach einigen Wochen, wer was entscheidet? Können Menschen bei Ihnen respektvoll widersprechen, Unsicherheit aussprechen und Fehler melden, ohne Nachteile zu befürchten? Wird Kritik an einer Aussage mit Ablehnung der Person verwechselt? Fragen Sie die Betroffenen selbst. Ein Austrittsgespräch, in dem Sie zuhören statt sich zu rechtfertigen, und ein Gespräch nach einigen Wochen mit Personen, die geblieben sind, liefern bessere Hinweise als Vermutungen. Werten Sie mehrere Abgänge gemeinsam aus, statt jeden Fall einzeln zu erklären.

Vor der Automatisierungsentscheidung, nicht erst bei Kommunikation, Schulung oder Stellenabbau. Jede Entscheidung darüber, welche Aufgaben ein System übernimmt, ist zugleich eine Entscheidung über Kompetenzen, Lernwege und Verantwortung.

Wird HR erst nach dem Entscheid einbezogen, ist die eigentliche Gestaltung der Arbeit bereits passiert: Aufgaben sind neu verteilt, Rollen faktisch neu geschnitten, Entscheidungsrechte stillschweigend vergeben. HR kann dann nur noch die Folgen erklären. Die Leitfrage lautet nicht, welche Stelle KI ersetzen kann, sondern welche Bestandteile einer Rolle sich automatisieren lassen, ohne Kompetenz und Verantwortung zu verlieren. Eine Rolle ist mehr als eine Liste von Tätigkeiten: Sie verbindet Routine, Fachwissen, Beziehungen, Urteil, Eskalation, Lernen und Verantwortung. Konkret heisst das: HR ist dabei, wenn der Umfang eines Automatisierungsprojekts festgelegt wird, bringt eine Aufgabenanalyse der betroffenen Rollen ein und klärt mit, wer nach der Einführung Ergebnisse prüft, Fehler erkennt und im Ernstfall eingreifen kann. Es geht nicht darum, Menschen gegen Technologie zu verteidigen, sondern dafür zu sorgen, dass die Organisation danach noch entscheiden, lernen und eingreifen kann.

Indem Sie die Lernwege bewusst neu bauen. Viele gut automatisierbare Aufgaben sind Einstiegsaufgaben, an denen Menschen den Normalfall lernen. Fallen sie weg, braucht es Mentoring, Fallbesprechungen, Übungsfälle und schrittweise übertragene Verantwortung.

Urteilskraft entsteht nicht allein durch Schulungen. Sie entsteht, weil jemand viele Fälle sieht, Muster erkennt, Fehler macht, Rückmeldung bekommt und schrittweise mehr Verantwortung übernimmt. Übernimmt ein System genau diese Fälle, gewinnt die Organisation kurzfristig Effizienz und kann zugleich den Weg vom Junior zum Senior verlieren. Fragen Sie deshalb vor jeder Automatisierung: Welche dieser Aufgaben sind heute Lernfelder? Wer lernt daran, und was genau? Wie lernt diese Person künftig dasselbe? Mögliche Lernwege sind Mentoring durch erfahrene Fachleute, regelmässige Fallreviews, Simulationen und Übungsfälle, Job Rotation, die gemeinsame Analyse von KI-Ergebnissen («Warum ist dieser Vorschlag falsch?») und bewusst vergebene Verantwortungsstufen: zuerst prüfen, dann mitentscheiden, dann selbst entscheiden. Planen Sie dafür Zeit erfahrener Mitarbeitender ein; ein Teil der Effizienzgewinne wird hier wieder gebraucht.

Planen Sie nicht nur Stellen, Vollzeitäquivalente und Skills, sondern ein Arbeitssystem aus Menschen, Technologie und Entscheidungsrechten. Die relevante Einheit ist die Kombination aus Aufgabe, Kompetenz und Entscheidungsrecht.

Die Aussage «40 Prozent dieser Stelle sind automatisierbar» ist nur der Anfang. Entscheidend ist, welche 40 Prozent gemeint sind: repetitive Aufgaben, Lernfelder für den Nachwuchs, Situationen, in denen Kundenbeziehungen entstehen, oder Vorarbeiten, die ein Mensch später beurteilen muss? Klären Sie für relevante Rollen gemeinsam mit den Fachbereichen fünf Fragen: Welche Aufgaben kann KI vollständig übernehmen? Welche darf sie vorbereiten, wenn Menschen sie danach prüfen? Wo braucht es Beziehung, Verhandlung oder situatives Urteil? Welche Aufgaben sind heute Lernfelder für die Fachkräfte von morgen? Wo muss ein Mensch im Ernstfall stoppen, korrigieren oder entscheiden können? Aus den Antworten ergeben sich Kapazität, Kompetenzbedarf und Entscheidungsrechte gemeinsam. Personalplanung wird damit stärker zu Organisationsdesign. Planen Sie auch die Prüfarbeit ein: Was ein System vorbereitet, muss jemand mit genügend Fachkenntnis beurteilen können.

Mehr diagnostisches Denken, nicht nur gutes Prompting. Je besser KI formuliert, desto wichtiger wird die Fähigkeit, gute von nur gut klingenden Antworten zu unterscheiden.

Generative KI ist stark darin, plausible Muster zu verdichten. Fragt man nach einem guten Führungsprofil oder nach Kriterien für Potenzial, erhält man oft vernünftige, sauber strukturierte Antworten, die für sehr unterschiedliche Unternehmen gleich plausibel sind. Bei Personalentscheidungen reicht das nicht, weil sie Folgen für konkrete Menschen haben. Gefragt sind bessere Fragen, Grundverständnis für Daten und Modelle und ebenso viel Klarheit über die eigene Kultur, Organisation und Verantwortung. Eine allgemein plausible KI-Antwort ist ein Ausgangspunkt, aber noch keine unternehmensspezifische HR-Entscheidung; woran sich generische Empfehlungen erkennen lassen, beschreibt eine eigene Frage. Ebenso wichtig ist Klarheit über Zuständigkeit: Wer verantwortet eine Empfehlung, die mit KI vorbereitet wurde? Die Stärke von HR liegt nicht darin, KI möglichst viel entscheiden zu lassen, sondern darin, sie so einzusetzen, dass das eigene Urteil besser wird.

Wenn erfahrene Mitarbeitende oder Partner gehen, verschwinden oft nicht zuerst Dokumente, sondern Zusammenhänge: weshalb Entscheide getroffen wurden, welche Ausnahmen gelten und wer informelle Abläufe kennt.

Sichern Sie vor Übergängen nicht nur Dateien und eine geregelte Übergabe von Konten und Berechtigungen, sondern auch Begründungen, Abhängigkeiten, offene Entscheide, Kontakte, bewährte Vorgehensweisen und bekannte Risiken. Hilfreich sind strukturierte Übergabegespräche, gemeinsame Fallbesprechungen, aktualisierte Prozessbeschreibungen und ein eindeutig verantworteter Wissensbestand. Entscheidend ist, dass Nachfolgende Informationen finden, verstehen und im Alltag anwenden können. Ein Archiv allein ersetzt die Weitergabe von Erfahrungswissen nicht. Passwörter dürfen dabei nicht informell weitergegeben werden.

Eine Zusammenarbeit beginnt mit einer kostenlosen Passungsklärung von 20 bis 30 Minuten über die aktuelle Situation, die Ziele und die offenen Fragen.

Dabei prüfen beide Seiten, ob die Aufgabe, die Erwartungen und die Art der Zusammenarbeit zusammenpassen. Falls noch keine belastbare Aufgabenstellung besteht, kann ein begrenzter Klärungsauftrag der erste Schritt sein.

Vor dem Start werden Rolle, Verantwortlichkeiten, Mitwirkung, erwartete Ergebnisse und organisatorische Rahmenbedingungen festgehalten. Damit entsteht eine gemeinsame Grundlage, an der die Zusammenarbeit später überprüft werden kann.

Ich erwarte Offenheit über die tatsächliche Situation, Zugang zu den relevanten Informationen und die Bereitschaft, notwendige Personen einzubeziehen.

Ebenso wichtig sind klare Ansprechpartner, erreichbare Entscheidungsträger und die Bereitschaft, Entscheidungen nicht dauerhaft aufzuschieben.

Verantwortung ist gegenseitig. Hosang Consulting übernimmt Verantwortung für die vereinbarte Rolle und die Qualität der eigenen Arbeit. Der Auftraggeber bleibt verantwortlich für seine Entscheidungen, seine Organisation und die erforderliche interne Mitwirkung.

Die notwendige Mitwirkung hängt vom Mandat ab. Sie wird zu Beginn konkret vereinbart.

Typischerweise braucht es Zugang zu relevanten Informationen und Personen, Zeit für Entscheidungen, ehrliche Rückmeldungen sowie die aktive Beteiligung derjenigen, die von einer Veränderung betroffen sind oder sie später tragen müssen.

Eine Transformation lässt sich nicht vollständig an externe Personen delegieren. Ich kann strukturieren, führen, herausfordern und umsetzen. Die Organisation muss jedoch bereit sein, Verantwortung zu übernehmen und Veränderungen im Alltag mitzutragen.

Ja. Das gehört zu meiner Verantwortung.

Ich spreche Risiken, Zielkonflikte, unrealistische Erwartungen, fehlende Fähigkeiten und unklare Verantwortlichkeiten frühzeitig an. Dies geschieht direkt, sachlich und respektvoll.

Mein Ziel ist nicht, möglichst konfliktfrei zu beraten. Mein Ziel ist, belastbare Entscheidungen und wirksame Umsetzung zu ermöglichen. Dazu gehört manchmal auch eine Einschätzung, die nicht den ursprünglichen Erwartungen entspricht.

Ich mache die Auswirkungen transparent und bespreche sie mit den verantwortlichen Personen.

Gemeinsam mit Ihnen prüfe ich, ob fehlende Voraussetzungen geschaffen, Ziele angepasst oder Rollen neu geklärt werden können. Dazu können beispielsweise zusätzliche Entscheidungen, verfügbare Ressourcen, der Einbezug weiterer Personen oder eine Reduktion des Auftrags gehören.

Wenn wesentliche Voraussetzungen dauerhaft fehlen, führe ich das Mandat nicht unverändert weiter. Ein Projekt formal fortzusetzen, obwohl keine realistische Grundlage für Wirkung besteht, wäre weder für den Auftraggeber noch für mich verantwortungsvoll.

Ja. Eine Beendigung kann notwendig sein, wenn entscheidende Voraussetzungen dauerhaft fehlen, vereinbarte Mitwirkung nicht erfolgt oder grundlegende Risiken bewusst ignoriert werden.

Einen solchen Schritt gehe ich nicht vorschnell. Zuerst mache ich die Situation transparent und prüfe gemeinsam mit Ihnen mögliche Anpassungen.

Bleibt dennoch kein realistischer Weg zu einer verantwortbaren Wirkung, empfehle ich eine Neuausrichtung oder Beendigung. Ein Mandat allein wegen seiner Laufzeit oder seines Umsatzes fortzuführen, entspricht nicht meinem Verständnis von Verantwortung.

Ich rechne nach Aufwand ab. Der Satz richtet sich nach Aufgabe, Verantwortung und Rahmenbedingungen und steht im Angebot.

Die erste Passungsklärung von 20 bis 30 Minuten ist kostenlos. Für jeden bezahlten Schritt vereinbaren wir vorab ein Kostendach.

Für ausgewählte soziale und christliche Projekte kann ich, insbesondere remote, auch unentgeltlich arbeiten. In bestimmten Situationen legen wir das Honorar gemeinsam fest. Entscheidend ist eine faire Vereinbarung für beide Seiten.

Sparring ist die kritische Reflexion konkreter Entscheidungen mit einer unabhängigen Person. Ich bringe Fragen, Erfahrung und Empfehlungen ein. Sie entscheiden selbst. Sinnvoll ist es, wenn Sie Ihre Annahmen hinterfragen und Verantwortung für die nächsten Schritte übernehmen möchten.

Sparring kann helfen, Entscheidungsoptionen, Zielkonflikte und Rollen in der Geschäftsleitung oder in Projekten zu klären. Ich bin direkt in der Sache und respektvoll gegenüber den Menschen. Anders als eine reine Bestätigung Ihrer Meinung soll das Gespräch neue Sichtweisen eröffnen. Ich gebe durchaus Einschätzungen und Empfehlungen ab, treffe aber nicht Ihre unternehmerischen Entscheide. Wenn medizinische oder psychische Beschwerden im Vordergrund stehen, ist eine entsprechende Fachperson zuständig. Sparring ist weder psychologische Beratung noch Therapie; Dauer und Form werden individuell vereinbart.

Zwei Ursachen lohnen sich zuerst zu prüfen: ob alle unter «Zusage» dasselbe verstehen, und ob Arbeit und Blockaden überhaupt sichtbar sind. Im Scrum Guide 2020 ist das Sprint-Ziel die Verpflichtung der Developers; welcher Umfang im Sprint fertig wird, ist eine Prognose, die im Sprint mit dem Product Owner neu verhandelt werden kann.

Begriffe klären: Im Scrum Guide 2020 hat jedes Artefakt eine Verpflichtung. Für das Sprint Backlog ist es das Sprint-Ziel, zu dem sich die Developers verpflichten. Das Sprint Backlog selbst ist ein Plan von und für die Developers. Der Umfang kann im Sprint mit dem Product Owner präzisiert und neu verhandelt werden, solange das Sprint-Ziel nicht gefährdet wird; die Planung des Umfangs bezeichnet der Guide als Prognose (forecast). Wer jede geplante Aufgabe als feste Zusage behandelt, misst das Team an etwas, das Scrum nicht als Zusage versteht. Danach die Ursachen prüfen, bevor jemand beschuldigt wird: Kam ungeplante Arbeit in den Sprint, etwa Störungen oder Zurufe? Wurden Prioritäten während des Sprints geändert? Hingen Einträge von anderen Teams oder Lieferanten ab? War die Definition of Done allen klar? Waren Einträge zu gross geplant? Und erfassen alle Teams Arbeit gleich, so dass Blockaden überhaupt sichtbar werden? In einer dokumentierten Entwicklungsorganisation mit Teams an mehreren Standorten erfasste jedes Team Arbeit anders. Sprint-Zusagen wurden gemacht und nicht gehalten, ohne dass jemand sagen konnte, woran es lag. Eingeführt wurden dort ein Kanban-Board über alle Teams, das Arbeit und Blockaden sichtbar machte, Sprint-Strukturen mit «expliziten Commitments», wie die Fallstudie sie nennt, und Retrospektiven, die zu tatsächlichen Prozessänderungen führten. Der Fallstudienbegriff «Commitment» ist nicht deckungsgleich mit der Verpflichtung im Sinn des Scrum Guide, die sich auf das Sprint-Ziel bezieht. Für die nächste Retrospektive: Nehmen Sie die letzten drei Sprints und markieren Sie bei jedem nicht erledigten Eintrag den Grund, etwa ungeplante Arbeit, Abhängigkeit, Umpriorisierung, Unterschätzung oder unklare Anforderung. Das Muster zeigt, wo eine Massnahme ansetzen muss, und verschiebt das Gespräch von Schuld zu Ursachen.

Indem eine Stelle auf Ihrer Seite die Verantwortung für das Zusammenspiel trägt, jede Schnittstelle zwischen den Lieferanten ausdrücklich Verantwortlichen zugeordnet ist und ein Gremium regelmässig und verbindlich entscheidet. Zum Engpass wird die Koordination, wenn jede Kleinigkeit über eine einzige Person laufen muss.

Mehrere Lieferanten liefern Teile, aber keiner von ihnen ist für das Ganze verantwortlich. Diese Verantwortung bleibt bei Ihrer Organisation als Auftraggeberin. HERMES 2022 sieht vor, dass interne und externe Leistungen vereinbart und periodisch mit Planung und Vereinbarungen abgeglichen werden; Abweichungen laufen über das Änderungsmanagement, wesentliche Probleme über die Problembehandlung. Steuert faktisch ein Lieferant, weil er das meiste Fachwissen hat, verschiebt sich Verantwortung unbemerkt. Hilfreiche Bausteine sind: eine Schnittstellenliste, in der jede Schnittstelle eine verantwortliche Person auf Lieferanten- und auf Auftraggeberseite hat; ein gemeinsamer Integrationsplan mit Abhängigkeiten statt getrennter Einzelpläne; ein wöchentliches Gremium mit dem Mandat, zu entscheiden, nicht nur zu informieren; eine klare Regel, was Lieferanten direkt untereinander klären dürfen; und eine Eskalationsfrist, nach der Ungelöstes an die nächste Ebene geht. Gerade die Regel für direkte Klärung verhindert den Engpass: Dürfen Lieferanten technische Detailfragen direkt lösen und gehen nur Entscheide mit Auswirkung auf Termin, Kosten, Qualität oder andere Lieferanten an die Koordination, bleibt diese handlungsfähig. In einem dokumentierten Mandat zur Geräteerneuerung in einem landesweiten Filialnetz hielten Koordinationsregeln mehrere Lieferanten in Deckung, ohne zum Engpass zu werden; wöchentliche Entscheidungsgremien hatten das Mandat, Themen zu entscheiden statt sie zu besprechen. Bei einer regulierten Self-Service-Lösung gehörten die Vorbereitung der Lieferantenauswahl, die Koordination individueller Hardware- und Softwareentwicklung und die Definition der Schnittstellen zur übernommenen Verantwortung.

Nicht zwingend. HERMES sieht selbst vor, den Umfang anzupassen: zuerst mit dem Sizing auf HERMES Online, danach bei Bedarf mit Tailoring. Für Kleinvorhaben unterhalb des Projekt-Schwellenwerts Ihrer Organisation gibt es zusätzlich die Variante HERMES One.

Das Referenzhandbuch hält fest, dass der volle Umfang für grosse Projekte mit hoher Komplexität ausgelegt ist, und empfiehlt Organisationen mit vorwiegend mittleren und kleinen Projekten, die Methode mit der Sizing-Funktion an die Grösse anzupassen. Das Sizing ermittelt aus einigen Angaben die Projektgrösse und liefert ein zugeschnittenes Szenario mit Durchführungsstrukturplan und Vorlagen. Laut Referenzhandbuch reduziert es Komplexität und Dokumentation auf das absolute Minimum, ohne die HERMES-Governance zu verletzen. Danach können Sie das Szenario per Tailoring weiter anpassen: nicht benötigte Module entfernen, Aufgaben und Ergebnisse streichen (ausser den minimal geforderten Dokumenten), eigene Module ergänzen oder Aufgaben und Ergebnisse hinzufügen. Die Bundeskanzlei hat das Sizing eingeführt, weil nach ihrer Darstellung die meisten Projekte relativ klein sind und viele Anwender mit dem früheren Tailoring überfordert waren. Für sehr einfache Vorhaben ist HERMES One gedacht, eine Vorlage für Kleinvorhaben unterhalb des Projekt-Schwellenwerts, den jede Organisation selbst festlegt. Laut HERMES Online ist die Governance nach HERMES 2022 damit nicht mehr gewährleistet. Muss Ihr Vorhaben gegenüber Revision, Aufsicht oder Geldgebern nach HERMES nachweisbar sein, empfehle ich das reguläre HERMES mit Sizing statt HERMES One. Eine Prüffrage, die nicht aus HERMES stammt, sondern meine Empfehlung aus der Praxis ist: Erstellen Sie ein Dokument nur, wenn jemand es für einen Entscheid oder eine Übergabe braucht. Drei Dinge sollten Sie aber auch im kleinen Vorhaben nicht weglassen: einen Auftraggeber mit Namen, ein schriftlich festgehaltenes Ziel und eine Abnahme am Ende. Diese drei Punkte gelten auch, wenn Sie gar nicht mit HERMES arbeiten.

Pflicht bleiben vier Module, drei Rollen und die minimal geforderten Dokumente der verwendeten Module. Sparen lässt sich vor allem über Sizing und Tailoring und bei agiler Umsetzung, indem die Detailspezifikation auf das Entwicklungswerkzeug verweist.

Damit die Projekt-Governance eingehalten ist, müssen laut Referenzhandbuch in jedem Projekt die Module Projektsteuerung, Projektführung, Projektgrundlagen und Einführungsorganisation vorkommen. Minimal zu besetzen sind die Rollen Auftraggeber, Projektleiter und Anwendervertreter. Diese Rollen und ihre Zugehörigkeit zur Partnergruppe Anwender dürfen auch bei organisationsspezifischen Anpassungen nicht verändert werden. Die minimal geforderten Dokumente sind obligatorisch. Dazu gehören etwa Projektinitialisierungsauftrag, Studie, Projektmanagementplan, Durchführungsauftrag, die Listen der Projektentscheide und die Projektschlussbeurteilung. Ist ein Modul für das Projekt nicht relevant, entfallen auch seine minimal geforderten Dokumente. Beim Tailoring lassen sich minimal geforderte Dokumente nicht streichen; eine Organisation kann die Liste aber gemäss ihren eigenen Governance-Bestimmungen anpassen. Am wirksamsten sparen Sie, wenn Sie zuerst das Sizing nutzen und erst danach gezielt zuschneiden. Bei agiler Umsetzung kann die Detailspezifikation laut Referenzhandbuch lediglich auf die Dokumentation im Entwicklungswerkzeug verweisen. Benutzerdefinierte Szenarien lassen sich herunterladen und mit anderen HERMES-Anwendern austauschen, sodass ähnliche Projekte nicht jedes Mal neu zugeschnitten werden müssen. Für alles, was über das Minimum hinausgeht, empfehle ich eine einfache Prüffrage: Wer braucht dieses Dokument für welchen Entscheid oder welche Übergabe? Findet sich niemand, ist es ein Kandidat zum Weglassen. Diese Regel stammt aus der Praxis, nicht aus HERMES.

Das ist keine Entweder-oder-Frage, weil beide Unterschiedliches regeln. HERMES ist eine Projektmanagementmethode und legt fest, was im Projekt wann entsteht und wer entscheidet. Die Individual Competence Baseline (ICB4) der IPMA beschreibt, welche Kompetenzen eine Person braucht, und schreibt keine Methode vor.

HERMES ist die Projektmanagementmethode der Schweizer Bundesverwaltung, herausgegeben von der Bundeskanzlei. Sie regelt Phasen, Meilensteine, Rollen, Aufgaben und Ergebnisse und stellt Vorlagen bereit. Das Referenzhandbuch setzt voraus, dass die Beteiligten eine Projektmanagement-Ausbildung oder zumindest fundierte Projektpraxis mitbringen. Die ICB4 der International Project Management Association beschreibt insgesamt 29 Kompetenzelemente in drei Bereichen: Kontext (5), persönliche und soziale Kompetenzen (10) und technische Kompetenzen (14); für das Projektmanagement sind 28 davon beschrieben, weil das 14. technische Element (Auswahl und Gleichgewicht) nur Programme und Portfolios betrifft. Sie versteht sich weder als Lehr- noch als Rezeptbuch, beschreibt keine Prozessschritte und steht neben Standards, die sich stärker auf Prozesse konzentrieren. In der Schweiz zertifiziert der VZPM Personen nach dem vierstufigen IPMA-System. HERMES beschreibt für jede Rolle benötigte Fähigkeiten, etwa Kommunikationsfähigkeit oder Entscheidungsfreudigkeit, aber kein Kompetenzmodell. Führung, Teamarbeit, Konflikte und Krisen oder Verhandlungen sind in der ICB4 eigene Kompetenzelemente. Umgekehrt gibt die ICB4 keine Phasen, Vorlagen oder Freigaben vor. Für eine Organisation heisst das: Eine Methode wie HERMES schafft eine gemeinsame Struktur und Sprache für Projekte; IPMA-Kompetenzen und -Zertifikate zeigen, ob Menschen in dieser Struktur führen können. Bei der Auswahl einer Projektleitung empfehle ich, beides getrennt zu prüfen: HERMES-Kenntnisse, wenn Ihre Organisation oder Ihr Auftraggeber HERMES verlangt, und Führungskompetenz, etwa über ein IPMA-Zertifikat ab Level C, für das der VZPM einen Bericht über ein eigenes Projekt und ein Interview beurteilt. Für die Entwicklung von Projektleitenden kann die ICB4 als Raster dienen, welche Fähigkeiten eine Methode voraussetzt, aber nicht vermittelt.

Ein IPMA-Zertifikat bestätigt Projektmanagement-Kompetenz nach dem vierstufigen IPMA-System, unabhängig von einer bestimmten Methode. Ab Level C prüft der VZPM in der Schweiz neben dem Wissen anhand eines Berichts über ein eigenes Projekt und eines Interviews auch die Anwendung. Ein Zertifikat gilt fünf Jahre; die Erstzertifizierung kostet laut VZPM je nach Level zwischen CHF 900 und CHF 5'900.

Level D bestätigt breites Wissen über Projektmanagement-Kompetenzen und setzt keine Praxis voraus; geprüft wird schriftlich. Ab Level C kommen Zulassungsbedingungen mit Berufserfahrung hinzu, und der VZPM beurteilt einen Bericht über ein reales eigenes Projekt und ein Interview; bei Level C und B kommt eine schriftliche Prüfung dazu, bei Level A nicht. Für Level C dauert der Prozess laut VZPM in der Regel acht bis neun Monate. Ein Zertifikat ist eine Momentaufnahme. Es sagt nichts über Branchen- und Fachwissen, über die Kenntnis einer bestimmten Methode wie HERMES oder über die Passung zu Ihrer Organisation; die zugrunde liegende ICB4 schreibt ausdrücklich keine Methode vor. Ich empfehle deshalb, nach dem Datum der letzten (Re-)Zertifizierung, nach Projekten seit der Zertifizierung und nach Referenzen aus vergleichbaren Vorhaben zu fragen. Für die Rezertifizierung der Levels A bis C sind laut VZPM in den fünf Jahren seit der letzten (Re-)Zertifizierung mindestens 30 Monate Praxis im Projekt-, Programm- oder Portfoliomanagement und mindestens 175 Stunden Weiterbildung nachzuweisen. Für Level D genügen 175 Stunden Weiterbildung, die teilweise durch Praxis abgedeckt werden können. Das Zertifikat darf höchstens sechs Monate abgelaufen sein, in begründeten Ausnahmefällen zwölf. Erstzertifizierung in öffentlichen Zertifizierungsrunden laut VZPM-Preisliste (gültig ab 1. März 2024, Version 9.0): Level D CHF 900, Level C CHF 3'200, Level B CHF 4'300, Level A CHF 5'900. Wer bereits ein gültiges tieferes Zertifikat hat, zahlt weniger, etwa für Level C mit Level D CHF 2'900. Für Level D gibt es reduzierte Preise in Unternehmen (CHF 800) und Bildungsinstituten (CHF 440) ab fünf Personen pro Runde. Die Rezertifizierung kostet für Level D CHF 250 und für die Levels A bis C CHF 600; im Zweifelsfall kann für A bis C ein Interview zu weiteren CHF 600 dazukommen. Vorbereitungskurse sind nicht inbegriffen.

Sie beschreiben steigende Verantwortung und Komplexität: Level D für breites Projektmanagementwissen und die Mitarbeit in Projekten, C für das Management von Projekten mit begrenzter Komplexität, B für komplexe Projekte, Programme oder Portfolios und A für sehr komplexe Projekte, Programme oder Portfolios auf strategischer Ebene.

Level D, Certified Project Management Associate: Nachweis breiten Wissens über Projektmanagement-Kompetenzen; keine Praxis erforderlich; Antrag mit Selbstbeurteilung und schriftliche Prüfung. Level C, Certified Project Manager: Projekte mit begrenzter Komplexität managen. Zulassung: in den letzten sechs Jahren mindestens drei Jahre Erfahrung als Projektleitung in begrenzt komplexen Projekten; in komplexen Projekten zählen nur die Rollen stellvertretende Projektleitung oder Teilprojektleitung. Verfahren: Antrag mit Executive Summary Report, schriftliche Prüfung, Bericht und Interview. Level B, Certified Senior Project Manager (analog für Programme und Portfolios): komplexe Projekte, Programme oder Portfolios managen. Zulassung: in den letzten acht Jahren mindestens fünf Jahre Erfahrung, davon mindestens drei in einer verantwortlichen Führungsfunktion in komplexen Vorhaben. Level A, Certified Project Director (analog Programme und Portfolio Director): sehr komplexe Projekte, Programme oder Portfolios auf strategischer Ebene managen; als Project Director in den letzten zwölf Jahren mindestens fünf Jahre in leitender Funktion, davon mindestens drei auf strategischer Ebene. Ich empfehle, das passende Level an der Komplexität Ihres Vorhabens zu messen, nicht nur an seiner Grösse. Ein Level ist ein Nachweis zu einem bestimmten Zeitpunkt; ob eine Person heute komplexere Vorhaben führt, zeigt erst das Gespräch über konkrete Projekte.

Agiles Vorgehen passt, wenn die Lösung erst durch Ausprobieren und Lernen entsteht und früh nutzbare Teile geliefert werden können. Weniger passend ist es, wenn die Lösung im Wesentlichen feststeht, nutzbare Teilergebnisse nicht früh möglich sind oder niemand mit Zeit und Entscheidungsbefugnis die fachlichen Anforderungen verantworten kann.

Der Scrum Guide beschreibt Scrum als leichtgewichtiges Rahmenwerk für komplexe Probleme. Es beruht auf Empirie: Man lernt aus Erfahrung und entscheidet auf Grundlage dessen, was beobachtet wurde. HERMES 2022 lässt klassische und agile Umsetzung zu und verlangt, dass die Wahl in der Initialisierung fachlich begründet wird, statt einem Trend zu folgen. Daraus lassen sich Prüffragen ableiten: Ist die Aufgabe tatsächlich offen, oder ist die Lösung weitgehend bekannt, etwa bei einer klar spezifizierten Beschaffung oder fest vorgegebenen Anforderungen? Lassen sich nutzbare Teilergebnisse früh liefern und von den Nutzenden prüfen? Gibt es eine Person, die die fachlichen Anforderungen mit Fachwissen, Zeit und Entscheidungsbefugnis verantwortet? Darf das Team Fehler machen und daraus lernen? Laut HERMES-Referenzhandbuch hält die Eidgenössische Finanzkontrolle eine Null-Fehler-Kultur für agiles Arbeiten für fatal. Fehlen diese Voraussetzungen, ist ein klassisches Vorgehen mit klaren Phasen und Freigaben oft ehrlicher als ein agiles Etikett. Die Wahl muss nicht einmal für das ganze Vorhaben gelten: In einem agilen HERMES-Projekt laufen Initialisierung und Abschluss klassisch, nur die Umsetzung erfolgt in Iterationen.

Ja. In der Publikation «Projektmanagement als Organisationsfähigkeit» verstehe ich Projektmanagement als den bewussten und geordneten Umgang einer ganzen Organisation mit Projekten: welche Vorhaben starten, wer über sie entscheidet, wie sie geführt werden, welche Informationen verlässlich sind und wie die Organisation aus ihnen lernt.

Die Leitung eines einzelnen Projekts mit Plan, Team und Budget bleibt wichtig, sie ist aber nur ein Teil. Dazu gehören auch die Auswahl der Vorhaben (Portfolio), der Rahmen aus Rollen und Entscheidungsrechten (Governance), eine gemeinsame Art, Vorhaben zu führen, verlässliche Führungsinformationen, passende Werkzeuge und das Lernen von Vorhaben zu Vorhaben. «Organisationsfähigkeit» meint: Projekte gelingen nicht nur, weil erfahrene Einzelpersonen sie tragen, sondern weil die Organisation einen geordneten, geteilten Weg hat. Erst dann wird das Vorgehen wiederholbar, vergleichbar und lernfähig, aus dem Können Einzelner wird das Können der Organisation. Das gilt für interne Veränderungen und Systemeinführungen ebenso wie für Kundenaufträge, die im Kerngeschäft als Projekte abgewickelt werden. Eine einfache Prüffrage: Würde Ihr nächstes wichtiges Vorhaben genauso verlässlich laufen, wenn die erfahrenste Person gerade nicht verfügbar wäre? Wenn nicht, hängt die Fähigkeit, Vorhaben verlässlich zu führen, noch stärker an Personen als an der Organisation.

Sobald Vorhaben einmalig, bereichsübergreifend und zeitlich begrenzt sind, in der Regel ja. Die Linie trägt das Dauerhafte, ein Projekt bündelt die Koordination für ein bestimmtes Ergebnis. Beide Logiken brauchen einander, und eine eigene Projektorganisation heisst nicht zwingend neue Stellen.

Die Linie, auch Stammorganisation genannt, trägt dauerhafte Verantwortlichkeiten, Prozesse und Wissen. Ein Projekt ist ein zeitlich begrenztes Vorhaben mit einem spezifischen Ergebnis und einer eigenen Koordinationsaufgabe. Das kann eine interne Veränderung sein, aber ebenso ein Kundenauftrag, der wegen seiner Einmaligkeit und der bereichsübergreifenden Zusammenarbeit als Projekt geführt wird. Linie und Projekt sind deshalb nicht dasselbe wie «Run» und «Change». Ein Unternehmen kann Kundenaufträge wiederkehrend als Teil seines Kerngeschäfts verkaufen und jeden einzelnen Auftrag trotzdem als Projekt führen. Die Linie ist dabei nicht Zuschauerin. Interne Veränderungsprojekte müssen ihre Ergebnisse in die Stammorganisation übergeben; projektförmige Kundenaufträge brauchen umgekehrt stabile Prozesse, Rollen und Wissen aus der Linie. In der Projektlandkarte zum Referenzmodell von Hosang Consulting, einer Orientierung ohne Pflichtcharakter, bestätigt die empfangende Organisation deshalb vor der Einführung ihre Einführungsbereitschaft, und über Abnahme beziehungsweise Wirkung entscheidet die Steuerung gemeinsam mit der empfangenden oder nutzenden Organisation. Für kleinere Organisationen empfehle ich, nicht mit neuen Stellen zu beginnen, sondern je Vorhaben ausdrücklich festzulegen: Auftrag und Ziel, wer entscheidet, wer das Vorhaben führt, und wer das Ergebnis in der Linie übernimmt.

Ein Projekttool unterstützt am besten eine geklärte Aufgabe, Zuständigkeiten und Informationen. Auch einfache digitale Hilfsmittel können früh helfen; sie ersetzen aber keine Führungsentscheidungen.

Was ungeordnet in ein System wandert, ist danach ungeordnet in einem System. Die Publikation «Projektmanagement als Organisationsfähigkeit» beschreibt den Griff zum Werkzeug als ersten der drei häufigsten Fehler beim Ordnen von Projekten; das ist eine Erfahrungsaussage, keine Zählung. Im Modell der acht Klärungsfelder von Hosang Consulting ist die Werkzeugfrage deshalb die siebte, nicht die erste. Digitale Unterstützung ist im überarbeiteten Reifegradmodell eine Querschnittsfähigkeit und kann schon früh helfen. Je stärker ein Werkzeug standardisierte Abläufe und Kennzahlen voraussetzt, desto wichtiger ist es allerdings, vorher die entsprechenden Aufgaben, Rollen und Informationen zu klären. Vor einer Anschaffung empfehle ich vier Prüffragen: Gibt es eine gemeinsame Art, ein Vorhaben zu führen, mit Phasen, Rollen und Entscheidungspunkten? Ist festgelegt, wer Vorhaben priorisiert, freigibt und stoppt? Welche Informationen soll das Werkzeug wem liefern, und wie verlässlich sind sie heute? In welchen bestehenden Systemen liegen die fachlichen Ergebnisse bereits? Ein Werkzeug kann durchaus ein konkretes Problem lösen, etwa wenn ein geklärter Ablauf nur noch nicht digital abgebildet ist oder Informationen an zu vielen Orten verstreut sind. Dann ist die Anschaffung kein Ersatz für Klärung, sondern ihre Unterstützung.

Hosang Consulting fasst das in einem eigenen Modell mit acht Klärungsfeldern zusammen: Zweck, Wertbeitrag, Portfolio, Governance, Projektführung, verlässliche Informationen, Werkzeuge und Lernen. Es ist eine bewusst gewählte Gliederung aus der Praxis, keine allgemeine Lehre und keine Checkliste.

Die acht Fragen lauten: 1. Wozu, und welche Vorhaben zahlen darauf ein? 2. Wie schaffen wir Wert, und was tragen Projekte dazu bei? 3. Welche Vorhaben starten wir, und welche nicht? 4. Wer entscheidet über die Vorhaben? 5. Wie führen wir ein einzelnes Vorhaben? 6. Worauf ist bei einem Vorhaben Verlass? 7. Welche Werkzeuge unterstützen Projekte? 8. Wie lernen wir von Vorhaben zu Vorhaben? Die Felder 1 und 2 betreffen Zweck und Wert, 3 und 4 Portfolio und Governance, 5 bis 8 Ausführung, Information, Werkzeuge und Lernen. Die Felder bauen aufeinander auf: Eine offene Frage weiter oben kann weiter unten Reibung erzeugen, die schliesslich als Stau in Projekten sichtbar wird. Die Reihenfolge lehnt sich an Simon Sineks «Warum, Wie, Was» an, das die Publikation als Denkquelle, nicht als Beleg nutzt. Kultur und Identität, das «Warum», setzt das Modell voraus; es stellt sie nicht her. Dass es genau acht Felder sind, ist keine Herleitung, sondern eine gewählte Gliederung: fein genug, um konkret zu sein, grob genug, um übersichtlich zu bleiben. Nicht zu verwechseln sind drei Sichtweisen derselben Publikation: Die Klärungsfelder fragen, was geklärt sein muss. Die fünf Verantwortungsebenen (Strategie, Portfolio, Steuerung, Führung, Abwicklung) fragen, wer welche Verantwortung trägt. Der Reifegrad fragt, wie weit die Organisation damit ist. Ein Klärungsfeld kann mehrere Ebenen zugleich betreffen. Für den Einstieg empfehle ich eine einfache Frage je Feld: Können wir sie heute klar und gemeinsam beantworten, und wo merken wir im Alltag, dass sie offen ist?

Eine Orientierung bietet das eigene, nicht empirisch validierte Reifegradmodell von Hosang Consulting mit fünf Stufen: personenabhängig, definiert und dokumentiert, organisationsweit standardisiert, aktiv gesteuert und gemessen sowie kontinuierlich verbessert. Digitale Werkzeuge können auf jeder Stufe helfen. Das Modell zeigt Entwicklungsmöglichkeiten, keine Benotung und keinen vorgeschriebenen Weg.

Die fünf Reifegrade beschreiben, wie aus individuellem Können eine zunehmend gemeinsam getragene Projektfähigkeit der Organisation entstehen kann. 1. Personenabhängig: Projekte gelingen vor allem dank einzelner erfahrener Menschen; Wissen und Entscheidungen hängen stark an ihnen. Ein nächster Schritt ist, erfolgskritische Grundlagen festzuhalten. 2. Definiert und dokumentiert: Rollen, Abläufe und Vorlagen sind teilweise beschrieben und in einzelnen Vorhaben angewendet; ihre Geltung über die gesamte Organisation ist noch nicht gesichert. Ein nächster Schritt ist eine verständliche, gemeinsame Grundlage. 3. Organisationsweit standardisiert: Gemeinsame Regeln und Vorgehensweisen werden in den relevanten Vorhaben tatsächlich angewendet und an Projektarten angepasst. Ein nächster Schritt ist, ihre Wirkung verlässlich zu steuern. 4. Aktiv gesteuert und gemessen: Die Führung nutzt geeignete Informationen und Kennzahlen zu Entscheidungsfristen, Ressourcen, Projektergebnissen und gegebenenfalls Nutzen, erkennt Abweichungen und reagiert bewusst. Messbarkeit ist hier Mittel zur Führung, nicht Selbstzweck. 5. Kontinuierlich verbessert: Die Organisation wertet Erfahrungen aus, prüft ihre Vorgehensweisen und verbessert Regeln, Vorlagen und Entscheidungen über einzelne Projekte hinaus. Lernen beginnt auf jeder Stufe; hier wird es systematisch und organisationsweit wirksam. Digitale Unterstützung ist keine fünfte Stufe, sondern ein Querschnittsthema: Schon eine einfache gemeinsame Ablage kann helfen; anspruchsvollere Systeme lohnen sich dort, wo Aufgaben und Informationen geklärt sind. Digitalisierung ersetzt weder Verantwortung noch Kultur. Dieses Fünf-Stufen-Modell ist eine eigene redaktionelle Orientierung, keine IPMA-Delta- oder CMMI-Bewertung. Es lehnt sich an deren Entwicklungslogik von personenbezogener Arbeit über definierte und angewendete Standards bis zu aktiver Steuerung und kontinuierlicher Verbesserung an. Die Stufen sind keine empirisch bewiesene Zwangsreihenfolge. Nicht jede Organisation muss die höchste Stufe anstreben. Massgebend sind die Bedeutung der Projekte, ihre Risiken, die Bedürfnisse und der vernünftige nächste Schritt. Nicht zu verwechseln ist dieses Gesamtbild mit dem Go-to-Market-Steuerungsmodell von Hosang Consulting, das jede seiner neun Prozessphasen gesondert auf den Stufen 0 bis 4 betrachtet. Eine praktische Standortfrage lautet: Was funktioniert bereits verlässlich, wo sind Verantwortlichkeiten oder Informationen noch personenabhängig, und welche Veränderung würde beim nächsten Vorhaben einen nachprüfbaren Nutzen bringen?

Die Vorbereitung ja, die Entscheidungen nein. Grundlagen erarbeiten, Informationen aufbereiten und Vorschläge ausarbeiten lässt sich delegieren. Was an der Führungsverantwortung hängt, etwa Prioritäten zwischen Vorhaben und Entscheidungsrechte, muss die Führung selbst entscheiden.

Die Publikation «Projektmanagement als Organisationsfähigkeit» beschreibt es als zweiten häufigen Fehler, die ganze Klärung einem Externen oder einer neuen Stelle zu überlassen. Als wiederkehrendes Muster in gescheiterten Vorhaben nennt sie, ausdrücklich als Erfahrungswert und nicht als Forschungsbefund: Führung, Beteiligte und Risiken werden zu Beginn nicht angesprochen, die oberste Leitung ergreift zu wenig Initiative, und zu viel Last liegt bei den Mitarbeitenden. Der Grund ist einfach: Wer Entscheidungsrechte festlegt, verteilt sie neu, und wer Prioritäten setzt, sagt auch, was nicht gemacht wird. Das kann eine externe Person oder eine neue Stelle vorbereiten, aber nicht mit der nötigen Legitimation entscheiden. Ich empfehle, die Arbeitsteilung von Anfang an ausdrücklich festzuhalten: was die externe Person oder die neue Stelle erarbeitet, bis wann, und wer wann darüber entscheidet. Eine mögliche Formulierung für den Auftrag: «Bitte bereiten Sie uns zwei bis drei Varianten mit ihren Folgen vor. Entscheiden werden wir in der Geschäftsleitung am vereinbarten Termin.» Ein Zeichen, dass die Klärung abgegeben statt delegiert wurde: Die Ergebnisse liegen vor, aber niemand in der Führung fühlt sich an sie gebunden.

Ein Prämortem ist ein kurzes Denkwerkzeug vor einer wichtigen Projektentscheidung: Die Beteiligten stellen sich vor, das Vorhaben sei in einem Jahr gescheitert, und schreiben jede und jeder für sich auf, wie es dazu kam. So werden Zweifel und Risiken sichtbar, bevor entschieden wird.

Die Methode stammt vom Psychologen Gary Klein und wurde 2007 in der Harvard Business Review beschrieben; Daniel Kahneman empfiehlt sie. Die Publikation «Projektmanagement als Organisationsfähigkeit» führt sie als Denkquelle, nicht als Beleg. Ein möglicher Ablauf, etwa in 30 bis 45 Minuten: Den Plan kurz vorstellen. Dann das Szenario setzen: «Stellen Sie sich vor, es ist ein Jahr später, und das Vorhaben ist gescheitert. Wie kam es dazu?» Alle schreiben einige Minuten still und einzeln. Danach liest jede Person reihum einen Punkt vor, ohne Diskussion, bis alles gesammelt ist. Zum Schluss werden die wichtigsten Punkte gebündelt und mit Massnahme und Verantwortung in den Plan aufgenommen. Der eigentliche Gewinn liegt nicht in den Antworten, sondern darin, dass Zweifel erlaubt und sogar verlangt sind. Wer sonst schweigt, weil er den Aufbruch nicht bremsen will, bekommt einen legitimen Ort dafür. Das stille, einzelne Schreiben verhindert, dass sich alle der ersten oder lautesten Meinung anschliessen. Grenzen: Ein Prämortem ist keine Prognose. Es kann auch Risiken hervorbringen, die real kaum bestehen, und es wirkt nur, wenn genannte Zweifel keine negativen Folgen für die Person haben.

Die beiden Modelle lassen sich als unterschiedliche, miteinander kombinierbare Perspektiven lesen. Das Referenzmodell beschreibt einen organisationsweiten Rahmen zur Führung von Vorhaben. Das Neun-Phasen-Modell beschreibt die Begleitung eines konkreten Vorhabens bis zur Wirkung und Übergabe. Diese Zuordnung ist eine redaktionelle Einordnung; die Quellen enthalten keine ausdrückliche Eins-zu-eins-Zuordnung.

Das Referenzmodell ist keine zusätzliche Projektmethode. Es spannt einen Bogen vom Projektimpuls bis zur Nutzung, bei Kundenprojekten bis zur Übergabe, mit Management-Meilensteinen, an denen die Führung entscheidet, während die eigentliche Projektabwicklung nach HERMES, PRINCE2, SAFe oder einer eigenen Vorgehensweise laufen kann. Das Neun-Phasen-Modell reicht von der Projektidee bis zu Wirkung und Rückzug. Zwischen den Phasen wird bewusst entschieden: weiterführen, anpassen, pausieren, beenden oder übergeben. Es regelt auch, welche Rolle die Beratung jeweils hat und wann sie zurücktritt. Eine Eins-zu-eins-Zuordnung der Phasen ist nicht dokumentiert. Als redaktionelle Lesart kann ein Mandat nach dem Neun-Phasen-Modell innerhalb eines Vorhabens stattfinden, das eine Organisation mit ihrem Referenzmodell führt.

Ja. HERMES eignet sich nicht nur für die Bundesverwaltung, sondern auch für Gemeinden, KMU und andere Organisationen. Entscheidend ist, die Methode an die Grösse, Komplexität und Risiken des Vorhabens anzupassen.

HERMES und PRINCE2 sind Projektmanagementmethoden mit unterschiedlichen Schwerpunkten. HERMES bietet insbesondere einen klaren Rahmen für Projektsteuerung, Verantwortlichkeiten, Ergebnisse und Entscheidungen. PRINCE2 verfolgt ebenfalls einen strukturierten Ansatz für die Führung und Steuerung von Projekten. PMI ist dagegen keine Methode, sondern ein Fachverband, der Projektmanagementstandards und Zertifizierungen anbietet. Diese Ansätze schliessen sich nicht gegenseitig aus. Ich empfehle deshalb keine Methode allein aufgrund ihres Namens, sondern prüfe, welcher Rahmen zur Organisation, ihren Entscheidungswegen und ihren konkreten Herausforderungen passt.

Ja. HERMES und Scrum lassen sich miteinander kombinieren. HERMES schafft den Rahmen für die Führung und Steuerung des Projekts, während Scrum die agile Entwicklung der Lösung organisiert.

HERMES definiert insbesondere Verantwortlichkeiten, Ergebnisse, Meilensteine und die notwendigen Entscheidungen. Innerhalb dieses Rahmens kann ein Scrum-Team die Lösung schrittweise entwickeln. Entscheidend ist, dass die Schnittstellen zwischen Projektsteuerung und agiler Umsetzung klar geregelt sind. Insbesondere muss feststehen, wer welche Entscheidungen trifft, wie Ergebnisse abgestimmt werden und wie die Projektverantwortlichen über den Fortschritt informiert bleiben.

Der HERMES-Auftraggeber verantwortet die übergeordnete Steuerung des Projekts. Er stellt die notwendigen Mittel sicher, trifft die ihm zugewiesenen Entscheide über die Durchführung, wesentliche Änderungen und die Fortführung des Projekts.

Das Scrum-Team organisiert dagegen seine Arbeit innerhalb der vereinbarten Ziele und Rahmenbedingungen selbst. Insbesondere entscheiden die Developers, wie sie die Arbeit zur Erreichung des Sprint-Ziels umsetzen. Selbstorganisation bedeutet jedoch nicht, dass das Team unabhängig von der Projektsteuerung handelt. Ziele, Budget, Verantwortlichkeiten und notwendige Entscheide müssen abgestimmt bleiben. Entscheidend ist deshalb eine klare Abgrenzung: Der Auftraggeber steuert das Projekt, während das Scrum-Team die konkrete Umsetzung innerhalb des vereinbarten Rahmens selbst organisiert.

Scrum-Artefakte wie das Product Backlog, das Sprint Backlog und das Increment ersetzen die in HERMES vorgesehenen Projektergebnisse nicht automatisch. Sie können jedoch dazu beitragen, diese Ergebnisse schrittweise zu erarbeiten und ihren Fortschritt transparent zu machen.

Welche HERMES-Ergebnisse tatsächlich benötigt werden, richtet sich nach dem gewählten Szenario und der projektspezifischen Anpassung der Methode. Formelle Entscheide bleiben insbesondere an den vorgesehenen HERMES-Meilensteinen erforderlich. Auch wesentliche Änderungen an Projektzielen, Budget oder Zeitrahmen können einen Entscheid der zuständigen Projektsteuerung notwendig machen. Änderungen innerhalb des bereits genehmigten Rahmens können dagegen durch die dafür verantwortlichen Rollen bearbeitet werden. Entscheidend ist, dass die Entscheidungsbefugnisse klar geregelt sind und die agile Arbeitsweise nicht durch unnötige Freigabeschritte behindert wird.

Für neue Projekte empfehle ich grundsätzlich die aktuelle Ausgabe HERMES 2022. Bei laufenden Projekten ist eine Umstellung nicht automatisch notwendig. Entscheidend sind die verbindlichen Vorgaben Ihrer Organisation und die Frage, welchen Nutzen beziehungsweise Aufwand ein Methodenwechsel verursacht.

Bestehende Vorlagen und Weisungen aus HERMES 5.1 sollten jedoch überprüft werden. HERMES 2022 hat unter anderem die Struktur der Methode, Rollen, Ergebnisse und das Zusammenspiel mit agilen Vorgehensweisen weiterentwickelt. Deshalb genügt es nicht, in bestehenden Dokumenten lediglich die Versionsnummer auszutauschen. Sinnvoll ist ein gezielter Abgleich der bisherigen Projektvorgaben mit der aktuellen Methode. Daraus lässt sich ableiten, welche Dokumente angepasst werden müssen und wo bestehende Regelungen weiterhin zweckmässig sind.

HERMES 2022 hat die Methode insbesondere im Zusammenspiel zwischen Projektsteuerung und Lösungsentwicklung weiterentwickelt.

Die wichtigste Änderung ist die klarere Trennung zwischen Projektmanagement und Entwicklungsmanagement. Dadurch kann eine Lösung sowohl klassisch als auch agil entwickelt werden, beispielsweise mit Scrum, während HERMES weiterhin die Projektorganisation, Verantwortlichkeiten, Ergebnisse und notwendigen Entscheidungen regelt. Zudem wurden die Szenarien und Module überarbeitet, die Rolle des Anwendervertreters gestärkt und die Anpassung der Methode an unterschiedliche Projektgrössen weiterentwickelt. Für Organisationen bedeutet dies, dass sie HERMES flexibler einsetzen können. Bestehende Projektvorgaben, Rollenbeschreibungen und Vorlagen sollten deshalb überprüft und bei Bedarf angepasst werden.

Nein. Eine Projektmanagementmethode schafft Strukturen, definiert Rollen, Verantwortlichkeiten, Abläufe und Entscheidungspunkte. Sie garantiert jedoch nicht, dass ein Projekt erfolgreich ist.

Entscheidend ist, wie die Methode in der Praxis angewendet wird. Verantwortliche müssen Entscheidungen treffen, Konflikte bearbeiten, Prioritäten setzen und die notwendigen Ressourcen sicherstellen. Auch die Eidgenössische Finanzkontrolle weist im HERMES-Referenzhandbuch darauf hin, dass die konsequente Anwendung einer Methode allein keinen Projekterfolg garantiert. Deshalb betrachte ich Projektmanagement nicht nur als Methodenfrage, sondern auch als Frage der Führung, Verantwortung und Entscheidungsfähigkeit einer Organisation.

HERMES definiert einen strukturierten Rahmen für das Projektmanagement. Dazu gehören Projektphasen, Meilensteine, Entscheidungsprozesse, Rollen, Aufgaben, Ergebnisse, Szenarien, Module und Vorlagen.

HERMES beschreibt zudem die Zusammenarbeit zwischen Projektorganisation und Stammorganisation. Die interne Organisationsstruktur, sämtliche Entscheidungsbefugnisse und die Führungsprozesse der Stammorganisation werden dadurch jedoch nicht vollständig festgelegt. Auch die konkrete Arbeitsweise bei der Entwicklung einer Lösung schreibt HERMES nicht generell vor. Innerhalb des Projektrahmens können beispielsweise klassische oder agile Vorgehensweisen wie Scrum eingesetzt werden. Entscheidend ist: HERMES schafft methodische Klarheit, ersetzt aber weder wirksame Führung noch fachliche Kompetenz, Verantwortungsübernahme oder notwendige Entscheidungen.

Kann Ihre Organisation wichtige Entscheidungen nur noch mit einer externen Person treffen, deutet dies eher auf fehlende interne Befähigung als auf zusätzlichen Beratungsbedarf hin. Dann steht der gezielte Aufbau von Wissen, klaren Rollen und Entscheidungsfähigkeit im eigenen Team im Vordergrund. Externe Beratung kann diesen Aufbau begleiten und unterstützen.

Typische Anzeichen: Fragen gehen an die Beraterin oder den Berater statt an das eigene Team. Entscheidungen kommen nur mit externer Unterstützung zustande. Das Wissen über Prozesse, Schnittstellen und Zusammenhänge liegt bei einer externen Person. Eine hilfreiche Prüffrage lautet: «Was würde in Ihrer Organisation ohne externe Unterstützung heute nicht mehr funktionieren?» Befähigung heisst nach meinem Verständnis: ein gemeinsames Verständnis von Ausgangslage und Ziel, klare Rollen und Entscheidungswege, nachvollziehbare Entscheidungen, die Fähigkeit zur Anwendung, Fehlererkennung und Weiterentwicklung sowie verteiltes Wissen statt Abhängigkeit von Einzelpersonen. Ein praktischer erster Schritt: Listen Sie die Entscheidungen und Aufgaben auf, die heute über die externe Person laufen. Legen Sie je Punkt eine interne verantwortliche Person und einen Zeitpunkt für die Übergabe fest, halten Sie das nötige Wissen schriftlich fest und verschieben Sie die externe Rolle schrittweise vom Ausführen zum Begleiten und Überprüfen. Neue Arbeitsweisen tragen erst, wenn sie wiederholt angewendet, von Führungskräften vorgelebt und im Alltag überprüft werden. Nicht jede dauerhafte externe Unterstützung ist ein Problem. Für seltene Spezialaufgaben kann sie bewusst die bessere Lösung sein. Kritisch wird es, wenn die Abhängigkeit niemand entschieden hat.

Ein Mandat kann enden, wenn Ihre Organisation die Arbeit selbst weiterführen kann: wenn sie ohne die externe Person entscheidet, Probleme selbst erkennt und bearbeitet und ihr Wissen anwenden und weitergeben kann.

Ich prüfe dafür fünf Kriterien: Ich muss in alltägliche Entscheidungen nicht mehr einbezogen werden. Die Beteiligten treffen selbstständig und nachvollziehbar gute Entscheidungen. Die Strukturen funktionieren in der Praxis. Probleme werden intern erkannt und bearbeitet. Die Organisation kann Wissen anwenden, vermitteln und weiterentwickeln. Sind diese Kriterien erfüllt, ist es Zeit zu gehen, nicht weil die Arbeit erledigt ist, sondern weil die Organisation sie selbst weiterführen kann. Zu meinen Grundsätzen gehört deshalb: «Ich verlängere kein Mandat, das mein Kunde selbst weiterführen könnte.» Ich empfehle, das Ende schon beim Start zu planen: Kriterien für die Übergabe vereinbaren, Zwischenpunkte festlegen und an jedem Prüfpunkt fragen, welche Entscheidungen noch an die externe Person gehen und weshalb. So wird das Ende eine bewusste Entscheidung und nicht ein Auslaufen. Davon zu unterscheiden ist der Abbruch eines Mandats, wenn keine realistische Wirkung mehr erreichbar ist. Diese Situation behandelt die Frage «Beenden Sie Mandate, wenn keine realistische Wirkung mehr erreichbar ist?».

Die Rolle, die das Vorhaben für den nächsten wirksamen Schritt braucht. Hosang Consulting unterscheidet dafür vier Rollen: Challenger, Accelerator, Executor und Observer. Ziele und strategische Entscheidungen bleiben in jeder Rolle beim Auftraggeber.

Das Rollenmodell ist eine Arbeitsweise von Hosang Consulting, kein allgemeiner Standard. Als Challenger hinterfrage ich Annahmen und mache Widersprüche und Risiken sichtbar. Als Accelerator schaffe ich Klarheit und Struktur und mache Hindernisse sichtbar. Als Executor übernehme ich operative Verantwortung für definierte Teile der Umsetzung. Als Observer trete ich zurück und prüfe, ob Verantwortung und neue Strukturen tragen. Die Rollen beschreiben den Schwerpunkt meiner Arbeit, begründen aber für sich allein keine Entscheidungsbefugnis. Welche operativen Entscheidungen ich vorbereiten, selbst treffen oder überprüfen darf, wird im jeweiligen Mandat ausdrücklich vereinbart. Ziele und strategische Entscheidungen bleiben beim Auftraggeber. Die Rollen sind keine starre Abfolge. Sie richten sich danach, wie weit eine Organisation eine Aufgabe schon selbst trägt, und können sich im Mandat ändern. Dabei gilt: Ich übernehme nur so viel Verantwortung wie nötig und gebe sie so früh wie verantwortbar zurück. Welche Rolle gilt, wird zu Beginn geklärt und im Verlauf überprüft. Ich empfehle, sie im Auftrag schriftlich festzuhalten, einschliesslich dessen, was ausdrücklich nicht dazugehört, und einen Rollenwechsel neu zu vereinbaren. Die vier Fragen dahinter helfen auch unabhängig von Hosang Consulting, wenn Sie externe Unterstützung beiziehen: Soll die Person vor allem hinterfragen, beschleunigen, selbst ausführen oder beobachten und prüfen? Unklare Erwartungen an diese Rolle führen leicht zu Enttäuschung auf beiden Seiten.

Die Passungsklärung von 20 bis 30 Minuten ist kostenlos. Ist danach eine Klärung nötig, ist sie der erste bezahlte Schritt, abgerechnet nach Aufwand mit einem vorab vereinbarten Kostendach. Ein Folgemandat ist damit nicht verbunden.

Die Passungsklärung ist kein Assessment und keine ausgearbeitete Lösung. Sie zeigt, ob Aufgabe, Zusammenarbeit und Rahmenbedingungen zueinander passen, und darf mit «passt nicht» enden. Ein kostenloses Assessment gibt es nicht: Muss eine Situation zuerst geklärt werden, ist diese Klärung bereits Arbeit und der erste bezahlte Schritt. Je nach Leistung heisst dieser Schritt unterschiedlich: Lageeinschätzung bei externer Projektleitung, Klärung vor einer wichtigen Entscheidung bei Business Analyse, Klärung bei Business Development, Einstieg bei der Mitarbeit im laufenden Vorhaben. Gemeinsam ist allen: ein abgegrenzter Auftrag, Abrechnung nach Aufwand und ein Kostendach, das vorab vereinbart wird. Das Ergebnis ist eine Entscheidungsgrundlage. Sie entscheiden, ob Sie weitergehen, das Vorhaben anpassen, zurückstellen, stoppen, intern weiterarbeiten oder einen anderen Spezialisten beiziehen. Eine Analyse verpflichtet nicht zu einer Anschlussbeauftragung; ein Folgemandat wird nur bei tatsächlichem Bedarf und ausdrücklich neu vereinbart. Bei jedem Anbieter lohnt es sich, vor einem bezahlten Einstieg vier Punkte festzuhalten: welche Fragen beantwortet werden, in welcher Form das Ergebnis vorliegt, wie hoch das Kostendach ist und was geschieht, wenn es erreicht wird. Halten Sie auch fest, dass das Ergebnis ausdrücklich «nicht weitermachen» lauten darf.

In fünf Schritten: Kennenlernen, Verstehen, gemeinsam Entscheiden, Umsetzen und Befähigen. Umfang und Dauer werden je Vorhaben vereinbart und nicht grösser gewählt als nötig. Ziel ist eine Organisation, die danach selbstständig weiterarbeiten kann.

Kennenlernen: eine kostenlose Passungsklärung von 20 bis 30 Minuten zu Situation, Zielen und möglichem Rahmen. Verstehen: Zusammenhänge analysieren, Perspektiven sichtbar machen und Fakten, Annahmen und Interpretationen unterscheiden. Gemeinsam entscheiden: Ziele, Prioritäten, Rollen und Verantwortlichkeiten werden gemeinsam erarbeitet; festlegen und verantworten Sie sie als Auftraggeber. Umsetzen: Ich übernehme die vereinbarte Verantwortung; meine Rolle kann sich dabei ändern, vom Hinterfragen über das Mitarbeiten bis zum Beobachten. Befähigen: Wissen wird weitergegeben, damit Menschen und Teams Entscheidungen zunehmend selbst treffen und Veränderungen eigenverantwortlich weiterführen. Die Schritte sind ein Orientierungsrahmen, kein starres Modell. Sie können je nach Ausgangslage unterschiedlich gewichtet, wiederholt oder parallel bearbeitet werden. Zur Dauer: Mandate können punktuell, über eine Projektphase oder über einen längeren Zeitraum laufen, auch kombiniert, etwa als intensive Klärungs- und Aufbauphase mit anschliessend reduzierter Begleitung. Umfang, Dauer und Einsatzrhythmus werden je Vorhaben festgelegt; allgemeine Richtwerte veröffentliche ich nicht. Ich empfehle, im Auftrag ein Enddatum oder ein Endkriterium und die Übergabe ausdrücklich festzuhalten.

Für die auf dieser Website beschriebenen Beratungs- und Projektmandate rechne ich grundsätzlich nach Aufwand ab. Für jeden bezahlten Schritt vereinbaren wir vorab ein Kostendach. Kurse mit festem Teilnahmepreis sind davon zu unterscheiden.

Der Satz richtet sich nach der Aufgabe, der übernommenen Verantwortung, den Rahmenbedingungen und der erwarteten Wirkung und steht im Angebot. Für die Mitarbeit in einem laufenden Vorhaben gilt ausdrücklich: Umfang, Dauer und Einsatzrhythmus werden pro Vorhaben festgelegt, ein Pauschalpaket gibt es nicht. Kostendach und Festpreis sind nicht dasselbe. Ein Festpreis setzt einen genau beschriebenen Leistungsumfang voraus und verschiebt das Risiko von Mehraufwand zum Anbieter, der dieses Risiko einpreisen wird. Ein Kostendach begrenzt Ihre Ausgaben für einen Schritt, während Sie den tatsächlichen Aufwand bezahlen. Es passt dort, wo der Umfang zu Beginn noch nicht vollständig feststeht, wie bei einer Klärung. Vereinbaren Sie in jedem Fall, was geschieht, wenn das Kostendach erreicht wird: abschliessen, neu entscheiden oder stoppen. In bestimmten Situationen lege ich das Honorar gemeinsam mit Ihnen fest; dabei kann auch die andere Seite sagen, welchen Preis sie für angemessen hält. Für ausgewählte soziale und christliche Projekte kann ich auch unentgeltlich arbeiten; das ist kein kommerzieller Referenzpreis. Kurse mit einem festen Teilnahmepreis, etwa ein Praxistraining, sind davon zu unterscheiden; sie sind keine Mandate.

Hosang Consulting ist das verantwortliche Zentrum eines Mandats.

Kunden arbeiten direkt mit den verantwortlichen Personen von Hosang Consulting. Wenn zusätzliche Kompetenzen notwendig sind, stelle ich ein passendes Team aus internen und externen Fachpersonen zusammen.

Damit verbinde ich persönliche Verantwortung mit der Möglichkeit, unterschiedliche Fachgebiete abzudecken. Es entsteht kein unnötig grosser Beratungsapparat, aber auch keine künstliche Begrenzung auf die Fähigkeiten einer einzelnen Person.

Zusätzliche Fachpersonen werden nach der konkreten Aufgabenstellung, ihrer fachlichen Kompetenz, ihrer Erfahrung und ihrer persönlichen Passung ausgewählt.

Entscheidend ist nicht nur, ob jemand ein Spezialgebiet beherrscht. Die Person muss auch zur Situation, zur Organisation und zur vereinbarten Arbeitsweise passen.

Hosang Consulting klärt Rollen und Schnittstellen, koordiniert die Zusammenarbeit und bleibt für die Gesamtführung des Mandats verantwortlich. Der Auftraggeber soll jederzeit wissen, wer welche Aufgabe übernimmt und wer für das Gesamtergebnis einsteht.

Decision Architecture bedeutet, aus komplexen Ausgangslagen eine verständliche Entscheidungsgrundlage zu schaffen: Informationen zusammenführen, Widersprüche sichtbar machen und Relevantes von Nebensächlichem trennen.

Mein Geschäftspartner Ralph Mattli übernimmt diese Rolle als Gründer von QUENARIS. QUENARIS verbindet Wissen, Entscheidungen, Rollen, Kontext und Erfahrungen über Menschen, digitale Mitarbeitende und externe Partner hinweg zu einem gemeinsamen Bild, mit dem Teams arbeiten können. Es unterstützt die Entscheidungs- und Umsetzungsarbeit, ersetzt aber weder bestehende Systeme noch menschliche Verantwortung. Die Entscheidung selbst bleibt immer bei den beteiligten Menschen.

In meiner Arbeit nutze ich QUENARIS als digitales Arbeits- und Organisationssystem. Offenlegung: Ich arbeite selbst auch bei Mattli Digital, das QUENARIS technisch umsetzt, und kann direkt Einfluss auf den Funktionsumfang nehmen. Hosang Consulting bleibt technologieoffen: QUENARIS ist eine mögliche Lösung, aber kein zwingendes Ergebnis eines Mandats. Wo QUENARIS Bestandteil einer Kundenlösung ist, wird das ausdrücklich vereinbart.

Organisationsgedächtnis bezeichnet das, was eine Organisation über sich selbst, ihre Entscheidungen und deren Begründung weiss – unabhängig davon, welche einzelnen Personen gerade da sind.

Es entsteht nicht von selbst. Wissen verlässt eine Organisation bei jedem Personalwechsel, an jeder Bereichsgrenze und bei jedem Ende einer externen Zusammenarbeit, wenn es niemand bewusst festhält. Ein Organisationsgedächtnis macht Erfahrungswissen anschlussfähig – für die nächste Entscheidung, nicht nur für die Ablage.

Coaching und Sparring für Führungskräfte biete ich selbst an, als Sparring & Befähigung.

Executive Search ist keine Leistung von Hosang Consulting. Wer eine Führungsposition besetzen will, dem stelle ich gerne den Kontakt zu meinem Geschäftspartner Heinz Brägger her, Partner und Practice Lead Change & Transformation bei Leverage Experts. Er bietet Executive Search eigenständig an.

Klärung vor einer wichtigen Entscheidung: klar begrenzte Analysen und Workshops, die eine tragfähige Entscheidungsgrundlage schaffen.

Führung eines Vorhabens auf Zeit: externe Projektleitung und befristete operative Führungsrollen in Vorhaben.

Externe Unterstützung und unabhängige Aussensicht: befristete Begleitung der Projektleitung, eine Standortbestimmung oder Mitarbeit an konkreten Aufgaben, wenn keine neue Projektleitung nötig ist. Führung und Entscheidungen bleiben bei Ihnen.

Transformation und Umsetzung: Transformationsmandate und operative Umsetzungsrollen, bei Bedarf mit gezielt beigezogenen Spezialisten.

Sparring und unabhängiger Review: punktuelle oder regelmässige Begleitung von Führungskräften und Projektverantwortlichen.

Mandate können punktuell, über eine definierte Projektphase oder über einen längeren Zeitraum erfolgen. Auch eine Kombination ist möglich, beispielsweise eine intensive Klärungs- und Aufbauphase mit anschliessender reduzierter Begleitung.

Das Modell richtet sich nach der Aufgabe und dem tatsächlichen Verantwortungsbedarf. Umfang und Laufzeit werden nicht grösser gewählt, als es für eine wirksame Bearbeitung notwendig ist.

Ja. Die Fallbeispiele enthalten ausdrücklich auch Vorhaben, die ihr Ziel nicht erreicht haben, und nennen die Grenzen der eigenen Rolle und der Ergebnisse.

Zwei Beispiele: Ein Testmodell für Familien während der Pandemie war fachlich und wirtschaftlich weit entwickelt, wurde aber nicht eingereicht, weil sich der vorgesehene Laborpartner kurz vorher zurückzog; die Fallstudie nennt sich selbst «keine klassische Erfolgsgeschichte». Ein Business-Development-Mandat habe ich früher beendet, weil die nötige Mitwirkung fehlte. Grenzen stehen im Text: Bei der landwirtschaftlichen Befähigung in Kenia ist von mehr als dreihundert Trainingsteilnahmen die Rede, ausdrücklich nicht von ebenso vielen Personen. Die Analyse eines Vertragsprozesses ist als persönliche Erfahrung aus dem eigenen Familienumfeld gekennzeichnet, nicht als Kundenmandat. Beim Familientest steht, dass das Pooling-Prinzip nicht von Hosang Consulting stammt. Kommerzielle Kundenfälle sind anonymisiert; bei ausgewählten Engagements werden freigegebene Projekt- und Partnernamen genannt. Für jede Fallstudie, auch bei anderen Anbietern, helfen vier Prüffragen: Welche Rolle hatte die Beratung genau, und wer trug die Verantwortung? Was wird als Ergebnis gezählt: Aktivitäten, Teilnahmen, eine Einführung oder eine nachweisbare Veränderung? Was wird ausdrücklich nicht beansprucht? Gibt es auch Fälle, in denen etwas nicht gelang, und was wurde daraus gelernt?

Hosang Consulting arbeitet hauptsächlich auf Deutsch und Englisch. Ich arbeite auch gerne auf Italienisch, kann Gespräche zudem auf Portugiesisch und Spanisch führen, und Französisch ist bei Bedarf möglich.

Welche Sprache sich für ein konkretes Mandat eignet, klären wir im ersten Gespräch. Gespräche und Workshops sind nach Absprache in Chur, bei Ihnen vor Ort oder online möglich. Bei mehrsprachigen Vorhaben empfehle ich, früh festzulegen, in welcher Sprache Entscheidungen, Protokolle und verbindliche Projektunterlagen geführt werden. Die Gesprächssprache in einem Workshop und die Sprache der massgebenden Dokumente dürfen sich unterscheiden; wichtig ist, dass alle wissen, welche Fassung gilt.

Der Schwerpunkt liegt bei Schweizer KMU; dazu kommen Gemeinden, öffentliche Organisationen und grössere Unternehmen. Eine feste Grössengrenze gibt es nicht: Entscheidend sind ein relevantes Vorhaben, klare Verantwortung und funktionierende Entscheidungswege.

Die Fallbeispiele sind nach zwölf Branchen geordnet: Öffentliche Verwaltung, Banking & Finanz, Logistik, Retail, Gastronomie, IT-Services, Industrie & IoT, Gesundheit, Energie und Investitionsprojekte, Mobilität, Nonprofit und Bildung. Zu grossen Vorhaben: Ich war unter anderem Teilprojektleiter in einem Konzernprogramm zur Geräteablösung mit 68 Mio. CHF Programmvolumen, Gesamtprojektleiter für sieben Releases einer Systemweiterentwicklung mit 10,47 Mio. CHF Volumen und rund 50 Beteiligten und habe ein internationales Team von 25 Personen in der Schweiz, Vietnam und Portugal geführt. Für grössere und internationale Transformationen kann ich das Senior-Netzwerk von Leverage Experts beiziehen und gezielt ein Team zusammenstellen. Sie erhalten dabei nicht automatisch ein grosses Beratungsteam, sondern die Kompetenzen, die die Aufgabe braucht. Sitz ist Chur. Ich arbeite in Graubünden, in der ganzen Schweiz und in internationalen Mandaten; für zusätzliche Kompetenzen oder lokale Präsenz greife ich auf ein Netzwerk erfahrener Senior Experts zurück. Branchenerfahrung ist ein Auswahlkriterium unter mehreren. Ebenso aussagekräftig ist oft Erfahrung mit vergleichbaren Situationen, etwa Vorhaben im laufenden Betrieb, viele Beteiligte oder regulierte Umfelder. Fragen Sie deshalb nach einem Fall, der Ihrer Situation ähnelt, nicht nur nach Ihrer Branche.

Beides, je nach Aufgabe. Hosang Consulting hat den Sitz in Chur; Gespräche und Workshops finden nach Absprache in Chur, bei Ihnen vor Ort oder online statt. Ich arbeite in Graubünden, in der Südostschweiz und in der ganzen Schweiz sowie in internationalen Mandaten.

Welche Form passt, klären wir zu Beginn eines Mandats. Für ein erstes Gespräch kann eine Videoverbindung genügen. Präsenz ist vor allem dort sinnvoll, wo mehrere Beteiligte gemeinsam eine Sicht erarbeiten, wo schwierige Entscheidungen oder Konflikte besprochen werden oder wo ich in einem laufenden Vorhaben mitarbeite. Der Grund: In solchen Situationen hängt viel davon ab, dass alle Beteiligten tatsächlich gehört werden und Rückfragen sofort möglich sind. Der Geschäftssitz ist an der Pargherastrasse 30, das Büro an der Pargherastrasse 31 in 7000 Chur. Graubünden ist meine Basis, nicht meine Grenze. Für Aufgaben, die zusätzliche Kompetenzen oder lokale Präsenz an einem anderen Ort erfordern, greife ich auf ein internationales Netzwerk erfahrener Senior Experts zurück. Für Ihre eigene Planung lohnt sich bei jedem externen Einsatz dieselbe Frage: Welche Termine brauchen Präsenz, und welche lassen sich ohne Verlust online führen? Wer das vorab festlegt, spart Reisezeit, ohne die Gespräche zu schwächen, auf die es ankommt.

Ja. Ich unterstütze Gemeinden und öffentliche Organisationen bei IT-, Organisations- und Digitalisierungsvorhaben. Veröffentlichte Beispiele betreffen eine Gemeinde im Kanton Bern mit Verwaltung und Schulen sowie mehrere Mandate auf Bundes- und Kantonsebene.

Gemeinde im Kanton Bern, IT-Analyse und Zielbild (abgeschlossen 2025): Die Informatik war über Verwaltung, Schulen und weitere Einheiten gewachsen. Als externer, unabhängiger Berater und Moderator habe ich Anwendungen, Geräte, Rollen, Zuständigkeiten und Dienstleister strukturiert betrachtet und in Workshops die Bedürfnisse der Bereiche aufgenommen. Daraus entstanden ein gemeinsames Zielbild, priorisierte Handlungsfelder und ein High-Level-Umsetzungsplan. Schulen derselben Gemeinde, pädagogische ICT- und Systemstrategie (laufend 2026): Unter- und Oberstufe arbeiten mit unterschiedlichen Geräte- und Plattformstrategien. Ich begleite die Gemeinde als unabhängiger Berater und Moderator mit Gesprächen mit Schulleitungen, der Analyse bestehender ICT-Konzepte, dem Vergleich mit anderen Schulen und Gemeinden sowie der Betrachtung von Support, Lebensdauer, Wiederverwendung und Kosten. Eine endgültige Geräte- oder Plattformentscheidung ist bewusst noch nicht getroffen. Bund und Kantone: In mehreren voneinander unabhängigen Mandaten habe ich die Modernisierung von IT-Arbeitsplätzen in Projekt-, Teilprojekt- und Spezialistenrollen unterstützt, von der Applikationsmigration über Softwarepakete, Qualitätssicherung und fachliche Abnahmen bis zur Übergabe in den Betrieb. Laut Stationenübersicht habe ich 2025 zudem eine Gemeindeverwaltung bei IT-Entscheidungen und ihrer organisatorischen Ausrichtung begleitet; Ort und Umfang sind nicht veröffentlicht. Eine Erkenntnis aus dem Schulmandat gilt für technische Entscheide allgemein: Ein Gerätewechsel und ein Plattformwechsel sind nicht dasselbe. Hardware lässt sich vergleichsweise einfach ersetzen. Eine über Jahre etablierte Plattform umfasst dagegen Arbeitsweisen, Unterrichtsmaterialien, Benutzerkonten, Prozesse, Know-how und Support. Wer zum Beispiel standardisieren will, sollte deshalb die organisatorischen und pädagogischen Folgen mitbeurteilen, nicht nur den Gerätepreis.

Andreas Hosang ist seit 2009 mit Hosang Consulting selbständig. Dahinter stehen Projekt-, Programm- und Transformationsrollen in Konzernen, KMU und öffentlichen Verwaltungen, die IPMA-Zertifizierung Level C seit 2023 und ein Vorstandsmandat im HERMES Connect Hub seit 2024.

Die Seite «Stationen» listet die Mandate seit 2009, unter anderem: IT-Migration und Softwarepaketierung in einem Grosskonzern als erstes Projekt, Teilprojektleitung in einem Konzernprogramm mit 68 Mio. CHF Volumen (2013 bis 2016), Gesamtprojektleitung für sieben Releases mit 10,47 Mio. CHF Volumen (2014), agile Führung eines internationalen Teams mit 25 Personen (2017 bis 2021), Rolle als Proxy Product Owner (2021), Digitalisierung mit Low-Code und KI (seit 2023) sowie ICT-Beratung und Coaching für öffentliche Verwaltungen (seit 2025). Methoden und Qualifikation: IPMA Level C (Certified Project Manager) seit 2023, gültig bis 2028; Erfahrung mit HERMES, IPMA, Scrum und SAFe; klassische, agile oder hybride Vorgehensweisen je nach Auftrag; seit 2024 im Vorstand des HERMES Connect Hub. Zertifizierungsvorbereitung und Methodenschulungen biete ich nicht an. Zur Einordnung: IPMA Level C bestätigt die Führung von Vorhaben mit begrenzter Komplexität oder von Teilprojekten in komplexen Vorhaben. Ein Zertifikat ist eine Momentaufnahme und ersetzt nicht Ihre eigene Prüfung. Prüfen Sie bei jeder externen Projektleitung die Stufe, das Datum der letzten Zertifizierung und Referenzen aus Vorhaben, die Ihrem ähneln. Was ein IPMA-Zertifikat aussagt, wie lange es gilt und was es kostet, beantwortet eine eigene Frage.

Mit den auf der Partnerseite vorgestellten Personen, mit denen ich für konkrete Vorhaben tatsächlich zusammenarbeite, projektbezogen, wiederkehrend und teils strategisch. Die Verantwortung für das jeweilige Mandat bleibt bei mir; wer welche Aufgabe übernimmt, wird vorab vereinbart.

Dorian Ferrari ist wie ich selbstständig und unterstützt mich als Geschäftspartner in der Projektleitung komplexer Vorhaben, mit HERMES ebenso wie mit agilen Vorgehensweisen und mit Erfahrung aus grossen und regulierten Umfeldern. Beim Angebot «Mitarbeit im laufenden Vorhaben» (Institut für angewandtes Projektversagen) arbeiten wir gemeinsam. Heinz Brägger ist mein Geschäftspartner für Executive Search, Führungskräftegewinnung und Veränderungssituationen; er ist Partner und Practice Lead Change & Transformation bei Leverage Experts und bietet Executive Search eigenständig an. Ralph Mattli ist mein Geschäfts- und Technologiepartner für Decision Architecture und Gründer und CEO von QUENARIS. Elizabeth Kunhimon ist Partnerin für HR & Recruiting. Angelo Hosang arbeitet seit 2024 punktuell mit, etwa bei Research und digitalen Inhalten, ohne eigenständige fachliche oder strategische Verantwortung. Kein Geschäftspartner, sondern ein digitales Teammitglied ist Ezra Luck: ein KI-Agent (Software) von MATTLI-DIGITAL und keine Person. Der Agent unterstützt Koordination und Dokumentation unter menschlicher Führung. Wie eng die Zusammenarbeit ist, unterscheidet sich je Vorhaben. Für Mandate von Hosang Consulting übernehme ich die Gesamtverantwortung; Partner arbeiten eigenständig in ihren vereinbarten Verantwortungsbereichen, und Auswahl, Koordination und Qualität verantwortet Hosang Consulting. Bei jedem Beratungsteam lohnt es sich, schriftlich zu klären: Wer ist Vertragspartner? Wer führt das Mandat und ist bei Problemen ansprechbar? Wer trägt welche Teilverantwortung, und wer hat welche Entscheidungsbefugnis?

Lösungsoptionen beurteile ich herstellerunabhängig, nach Aufgabe und Anforderungen. Wo ich selbst mit einer Lösung oder einem Anbieter verbunden bin, lege ich das offen. Veröffentlicht sind heute meine Verbindung zu QUENARIS über Mattli Digital sowie meine selbstständige Tätigkeit für Leverage Experts.

Bei Software-, ERP- oder Plattformentscheidungen berücksichtige ich unterschiedliche Anbieter und Technologien: internationale Plattformen wie Microsoft 365 und Power Platform ebenso wie Schweizer Softwarelösungen, spezialisierte Anwendungen und Open-Source-Produkte. Massgebend sind die Anforderungen, die Integration in bestehende Systeme, Kosten, Sicherheit, Datenschutz und der langfristige Betrieb. Oft lohnt es sich zuerst zu prüfen, was mit den bestehenden Systemen möglich ist. Offenlegung: Ralph Mattli, Gründer von QUENARIS, ist mein Geschäftspartner. Ich arbeite selbst auch bei Mattli Digital, das QUENARIS technisch umsetzt, und kann Einfluss auf den Funktionsumfang nehmen. Ich nutze QUENARIS selbst als digitales Arbeits- und Organisationssystem. QUENARIS ist eine mögliche Lösung, aber kein zwingendes Ergebnis eines Mandats; steht es in einer Technologieentscheidung zur Wahl, sage ich das ausdrücklich, und wo QUENARIS Bestandteil einer Kundenlösung ist, wird das ausdrücklich vereinbart. Zur Transparenz: Seit April 2023 bin ich zudem selbstständig im Business Development und Partner Management für Leverage Experts tätig. Für grössere und internationale Vorhaben kann ich deren Senior-Netzwerk beiziehen; mein Geschäftspartner Heinz Brägger ist dort Partner. Mein Grundsatz lautet: «Wo ich selbst an einer Empfehlung oder Entscheidung verdiene, sage ich es. Reicht das nicht, entscheide ich nicht selbst.» Die Entscheidung bleibt ohnehin bei Ihnen. Bei einer offengelegten Verbindung empfehle ich, die Bewertung durch eine zweite, unabhängige Person gegenlesen zu lassen. Unabhängig davon, mit wem Sie arbeiten, helfen vor jeder Technologieempfehlung drei Fragen: Ist die beratende Person an einem Anbieter beteiligt, arbeitet sie dort oder erhält sie Provisionen oder Partnervorteile? Wurden die Bewertungskriterien festgelegt, bevor Produkte verglichen wurden? Wurde mindestens eine Alternative ernsthaft geprüft, einschliesslich der Weiterführung des Bestehenden?

Zu Beginn kläre ich, welche konkrete Veränderung mit dem Mandat erreicht werden soll und woran diese erkennbar ist.

Je nach Aufgabe kann Wirkung beispielsweise in klareren Entscheidungen, stabileren Abläufen, geklärten Verantwortlichkeiten, einer erfolgreichen Einführung, einer verbesserten Zusammenarbeit oder einer selbstständig handlungsfähigen Organisation bestehen.

Die Kriterien werden nicht erst am Ende betrachtet. Ich überprüfe während des Mandats regelmässig, ob die gewählten Massnahmen tatsächlich zur vereinbarten Wirkung beitragen. Wenn dies nicht der Fall ist, passe ich das Vorgehen an oder stelle die zugrunde liegenden Annahmen erneut infrage.

Ich beziehe bestehende Teams und Verantwortliche frühzeitig ein. Wissen, Entscheidungsgrundlagen, Rollen und Arbeitsweisen werden nachvollziehbar dokumentiert und gemeinsam aufgebaut.

Wo ich vorübergehend eine operative oder führende Rolle übernehme, plane ich auch die Übergabe dieser Verantwortung. Ziel ist eine Organisation, die nach dem Mandat eigenständig weiterarbeiten und neue Situationen selbst beurteilen kann.

Externe Unterstützung kann weiterhin sinnvoll sein. Sie sollte jedoch eine bewusste Entscheidung sein und nicht die Folge davon, dass Wissen oder Verantwortung absichtlich bei der Beratung zurückgehalten wurden.

Wenn es niemand ausdrücklich ist, oft niemand. Legen Sie schon beim Entscheid fest, wer nach dem Projektende prüft, ob die Massnahme etwas verändert hat, wann und woran; ohne diese Rückverbindung von Wirkung zu Entscheid lernt eine Organisation kaum aus ihren Ergebnissen.

Eine Entscheidung ist der Anfang einer Kette: Entscheid, Massnahme, Umsetzung, Wirkung, Erkenntnis, Lernen. Nach der veröffentlichten Erfahrung von Hosang Consulting funktionieren die ersten drei Glieder meist gut. Bei den letzten drei wird es dünner, weil das Projekt offiziell beendet und das Team bereits im nächsten Vorhaben ist; die Frage nach der Wirkung hat dann keinen Platz mehr im Kalender. Die Folge: Ohne Rückverbindung wiederholt eine Organisation Muster, statt sie zu korrigieren, weil niemand mehr weiss, welcher frühere Entscheid zu welchem Ergebnis geführt hat. Hosang Consulting beschreibt als typische Fähigkeitslücke, dass ein Projekt zwar Sponsor und Projektleitung hat, aber niemanden, der nach Projektende für das Ergebnis im Alltag verantwortlich bleibt. Praktisch empfehle ich: Benennen Sie eine wirkungsverantwortliche Person in der Linie, nicht im Projekt, das endet. Halten Sie im Projektabschluss fest, welche Wirkung erwartet wird, woran sie erkennbar ist und wann sie geprüft wird. Verknüpfen Sie das Ergebnis mit dem ursprünglichen Entscheidungsvermerk und nehmen Sie die Erkenntnisse in die nächsten Entscheide mit. Ein Entscheid ist nicht erledigt, wenn die Massnahme abgeschlossen ist, sondern wenn ihre Wirkung bekannt ist.

«Umgesetzt» belegt einen Output, nicht die Wirkung. Wirkung messen Sie mit Früh- und Spätindikatoren, die zum konkreten Vorhaben passen: Frühindikatoren zeigen, ob es in die gewünschte Richtung geht, Spätindikatoren, ob die Wirkung eingetreten ist.

Ein abgeschlossener Workshop oder ein eingeführtes System ist ein Output. Ob sich danach Zusammenarbeit, Entscheidungsverhalten oder Nutzung verändert haben, ist der Outcome. Viele Berichte enden beim Output, weil er einfacher zu belegen ist; eine ehrliche Antwort auf die Frage, ob es gewirkt hat, braucht Zeit, Abstand und manchmal den Mut zu einer unbequemen Antwort. Beispiele, die Hosang Consulting verwendet: Früh erkennbar sind etwa die Qualität und Offenheit der Gespräche, ein gemeinsameres Verständnis der Ausgangslage, klarere Ziele, Rollen und Verantwortlichkeiten, sichtbare Annahmen und Risiken sowie schnellere und nachvollziehbarere Entscheidungen. Später erkennbar sind die tatsächliche Nutzung neuer Systeme und Arbeitsweisen, Stabilität im Alltag, Akzeptanz, messbar bessere organisatorische Ergebnisse, geringere Abhängigkeit von einzelnen Personen oder externer Beratung und die Fähigkeit zur selbstständigen Weiterentwicklung. Vereinbaren Sie Ziel, erwartetes Ergebnis und Messkriterien zu Beginn, Ziele wo sinnvoll nach dem SMART-Prinzip. Messen Sie, was für die vereinbarte Wirkung relevant ist, nicht nur, was leicht messbar ist. Fehlen zu Beginn belastbare Daten, ist das kein Freipass: Benennen Sie es als Teil der Ausgangslage und verbessern Sie die Messbarkeit schrittweise. Messung dient Entscheidung und Lernen, nicht sich selbst.

Wissenschaftliche Studien zeigen positive statistische Zusammenhänge zwischen wirksamen Projektmanagementpraktiken und Projekterfolg. Teilweise finden sich auch Zusammenhänge mit der wirtschaftlichen Leistung von Unternehmen. Eine allgemeine oder kausal gesicherte Rendite für jede zusätzliche Investition in Projektmanagement ist damit nicht belegt. Entscheidend ist, welche konkreten Probleme gelöst und welche Verbesserungen tatsächlich erreicht werden.

Positive Befunde gibt es: Mir und Pinnington (2014) untersuchten 154 Antworten von Projektfachpersonen und fanden einen statistisch signifikanten Zusammenhang zwischen der Leistung des Projektmanagements und dem Projekterfolg. Ihr Modell erklärte rund 44,9 Prozent der Unterschiede in den gemessenen Projekterfolgswerten. Joslin und Müller (2015) werteten 254 internationale Antworten aus; die Anwendung einer Projektmanagementmethodik erklärte 22,3 Prozent der statistischen Unterschiede im Projekterfolg. Beide Prozentzahlen beziehen sich auf erklärte Varianz, nicht auf Umsatzsteigerung, Rendite oder nachgewiesene Kausalität. Für die Leistung des Gesamtunternehmens ist die Datenlage schwieriger: Yazici (2009) berichtete bei 86 Fachpersonen einen Zusammenhang zwischen wahrgenommener Projektmanagement-Reife und wahrgenommener Geschäftsleistung, nicht aber zwischen Reife und Projektleistung; Organisationskultur spielte eine eigenständige Rolle. Die Ergebnisse hängen von Messung, Umfeld und untersuchten Organisationen ab. Eine allgemeine ROI-Garantie lässt sich daraus nicht ableiten. Ich empfehle deshalb, zuerst das betriebliche Problem und die Ausgangslage zu benennen: Sind Entscheidungsfristen zu lang, Statusinformationen unverlässlich, Ressourcen mehrfach verplant, Übergaben mangelhaft oder Ziele unklar? Legen Sie vor einer Veränderung geeignete Indikatoren fest, etwa eingehaltene Entscheidungstermine, Durchlaufzeiten, vergleichbare Statusmeldungen, Nacharbeit oder einen belegbaren Nutzen im Betrieb. Prüfen Sie später, was sich verbessert hat, welche Kosten die Veränderung verursachte und welche weiteren Einflussfaktoren es gab. Auch ein schlanker Rahmen oder der bewusste Verzicht auf zusätzliche Bürokratie kann das richtige Ergebnis sein.

Häufig, weil Erkenntnisse zwar erfasst, beim nächsten Vorhaben aber nicht wieder verfügbar gemacht und genutzt werden; darauf weisen Forschung und Praxiserfahrung hin, ein strenger Nachweis fehlt. Wirksam wird Lernen erst, wenn es in die Art einfliesst, wie das nächste Vorhaben vorbereitet und geführt wird.

Die Forschung weist auf eine Lücke zwischen Verfahren und Praxis hin: In Befragungen von Projektleitenden gibt ein grosser Teil an, ein formales Verfahren für Lessons Learned zu haben, aber nur ein kleiner Teil hält sich tatsächlich daran. Die Publikation «Projektmanagement als Organisationsfähigkeit» kennt diesen Befund aus zweiter Hand und führt ihn ausdrücklich als Hinweis, nicht als Beleg. Als Erfahrung und These beschreibt die Publikation, was danach typischerweise geschieht: Die Erkenntnisse wandern in Ablagen, die zu stillen Archiven werden. Was überlebt, sind Formulare und Vorlagen, nicht die eigentlichen Erkenntnisse. Das wertvolle Wissen, das beim Übergang eines Vorhabens in den Betrieb entsteht, hängt an Personen und geht mit ihnen. Ich empfehle, Lernen am Anfang statt am Ende zu verankern: Bei der Initialisierung eines neuen Vorhabens drei bis fünf Erkenntnisse aus vergleichbaren Vorhaben ausdrücklich prüfen. Erkenntnisse kurz, konkret und mit einer verantwortlichen Person festhalten. Und wo möglich nicht nur einen Bericht schreiben, sondern Vorlage, Checkliste oder Ablauf direkt anpassen, damit die Erkenntnis beim nächsten Mal von selbst wirkt. Im Modell der acht Klärungsfelder von Hosang Consulting ist das Lernen von Vorhaben zu Vorhaben das achte Feld; ohne es bleibt nach der Publikation jede Verbesserung ein Einzelfall.

Eine einzelne Ursache gibt es nicht. Ein Muster, das die Publikation «Projektmanagement als Organisationsfähigkeit» als Erfahrung und These beschreibt: Man klärt die angenehm strategischen Fragen und bleibt dort stehen, wo es um Entscheidungsrechte und gewachsene Gewohnheiten geht, weil diese Klärung Einfluss kostet.

Veränderungsvorhaben können aus organisatorischen, kommunikativen oder führungsbezogenen Gründen ins Stocken geraten. Das beschriebene Muster ist ein bestimmtes: Die oberen Fragen kosten Nachdenken, die nachfolgenden kosten Einfluss. Wer Entscheidungsrechte festlegt, verteilt sie neu, und wer gewachsene Gewohnheiten ordnet, spricht aus, was bisher unausgesprochen galt. Das tritt nach der Publikation in gut geführten Häusern genauso auf wie anderswo. Zurück bleibt eine klare Absicht, deren Umsetzung an den ungeklärten Fragen scheitert. Dazu kommt, dass sich in Diskussionen nicht immer der beste Vorschlag durchsetzt, sondern häufig der am besten vorgetragene (Erfahrung und These). Daniel Kahneman beschreibt, dass Sicherheit im Auftreten als Kompetenz gelesen wird; die Publikation nutzt das als Denkquelle, nicht als Beleg. Ein sichtbarer Entscheidungsweg hilft dort, wo eine Organisation Widerspruch aushält. Ob Sichtbarkeit Machtverhältnisse tatsächlich ändert, ist offen. Was helfen kann: Benennen Sie ausdrücklich, welche Entscheidungsrechte sich ändern und für wen. Lassen Sie Vorschläge vor der Sitzung schriftlich mit Annahmen einreichen, damit Inhalt und Vortrag getrennt beurteilt werden können. Fragen Sie bei Zahlen, womit sie verglichen wurden. Und achten Sie darauf, wer wann welche Zahl wie sicher vorträgt. Eine Grenze bleibt: Konfliktfähigkeit ist eine Voraussetzung, die keine Methode herstellt. Klärung kann den Ort schaffen, an dem Annahmen und Entscheidungen sichtbar werden; ob eine Organisation aushält, was sie dort sieht, entscheidet sie selbst.

Indem Sie nicht die Methoden vereinheitlichen, sondern die Führungspunkte darüber: gemeinsame Entscheidungsmomente, vergleichbare Statusinformationen und klare Entscheidungsrechte. Hosang Consulting beschreibt dafür ein methodenneutrales Referenzmodell als Führungsrahmen; die bewährte Methode darunter kann bleiben.

Ein Bauprojekt folgt einer anderen Logik als eine Softwareentwicklung, ein Organisationsprojekt einer anderen als eine Beschaffung. Unterschiedliche Vorgehen wie HERMES, PRINCE2, SAFe, SIA, agile Ansätze oder eine eigene Vorgehensweise sind deshalb kein Problem. Schwierig wird es, wenn mit jeder Projektart auch die gemeinsame Führung verschwindet: Jedes Vorhaben spricht eine andere Sprache, kennt andere Entscheidungspunkte und beschreibt seinen Status anders. Das Referenzmodell von Hosang Consulting ist keine zusätzliche Projektmethode, sondern ein Führungsrahmen über den Methoden. Es spannt einen Bogen vom Projektimpuls bis zur Nutzung oder Übergabe und legt Management-Meilensteine fest, an denen die Führung entscheidet. Darunter darf die Abwicklung verschieden bleiben. Methodenneutral heisst nicht strukturlos. Dazu gehört Tailoring: eine vorhandene Vorgehensweise bewusst an den konkreten Kontext anpassen, weil nicht jedes Projekt denselben Umfang an Dokumentation, Rollen, Kontrollen oder Arbeitsschritten braucht. Tailoring ist eine bewusste Anpassung, keine beliebige Auflösung der Methode. PRINCE2 etwa kennt diesen Gedanken ausdrücklich. Praktisch empfehle ich zwei Schritte: Ordnen Sie die Phasen und Entscheidungspunkte jeder verwendeten Methode den gemeinsamen Führungspunkten zu. Und vereinbaren Sie ein minimales gemeinsames Statusformat, etwa Termine, Kosten, Qualität, Umfang, Risiken und nächste Entscheide, das jedes Vorhaben unabhängig von seiner Methode liefert.

Beginnen Sie mit der Initialisierung: einen Auftraggeber als Person bestimmen, Projektleitung und Anwendervertretung beim Anwender besetzen, in einer Studie Varianten vergleichen und dann Variante, Szenario und Vorgehen festlegen. Für die Beschaffung und Einführung einer am Markt verfügbaren Software sieht HERMES das Szenario IT-Adaption vor.

Bestimmen Sie zuerst den Auftraggeber: eine einzige natürliche Person aus Ihrer Verwaltung oder Behörde, beim Anwender angesiedelt und mit Entscheidungskompetenz gemäss Ihrer Kompetenzordnung. Er bestimmt den Projektleiter und den Anwendervertreter; beide müssen beim Anwender angesiedelt sein. Auf eine Projektleitung, die der Softwarelieferant stellt, ist laut HERMES wegen möglicher Interessenkonflikte zu verzichten. Sollen Gemeinderat oder Kommission einbezogen werden, eignet sich ein Projektausschuss, dessen Mitglieder und Stimmrecht der Auftraggeber festlegt. In der Initialisierung entstehen unter anderem Projektinitialisierungsauftrag, Studie mit Lösungsvarianten, Rechtsgrundlagenanalyse, Schutzbedarfsanalyse und bei Beschaffungen eine Beschaffungsanalyse. Danach wird entschieden, welche Variante, welches Szenario und ob klassisch oder agil umgesetzt wird. Für die Beschaffung, Anpassung und Integration einer Standardsoftware ist das Szenario IT-Adaption vorgesehen; es umfasst unter anderem die Module Beschaffung, Organisation, IT-System, Tests, IT-Migration, IT-Betrieb und ISDS. Mit dem Sizing auf HERMES Online passen Sie den Umfang an die Grösse des Vorhabens an. Mit Durchführungsauftrag und Projektmanagementplan wird die Durchführungsfreigabe vorbereitet. Der Auftraggeber entscheidet in Abstimmung mit der Stammorganisation, bei einer Gemeinde zum Beispiel im Rahmen der Kompetenzen und Kredite, die ihm die zuständige Behörde erteilt hat. Danach folgen bei klassischem Vorgehen Konzept, Realisierung und Einführung mit Phasenfreigaben, bei agilem Vorgehen die Umsetzung in Releases. Bei der Beschaffung entscheidet der Auftraggeber auch über die Ausschreibung und den Zuschlag. Als Empfehlung drei Punkte, die in Gemeinden besondere Aufmerksamkeit verdienen: Klären Sie früh, welche Beschaffungsregeln für den Auftragswert gelten, denn sie bestimmen Zeitplan und Ausschreibungsunterlagen. Planen Sie Informationssicherheit und Datenschutz über das Modul ISDS von Anfang an ein, besonders wenn Personendaten der Einwohnerinnen und Einwohner betroffen sind. Und legen Sie fest, wer die Lösung nach dem Projekt betreibt und weiterentwickelt, denn das Projekt endet mit dem Übergang an die Anwendungsorganisation.

Ich empfehle, das nicht allein anhand der Hardware zu entscheiden, sondern zu prüfen, welche Kombination aus Nutzung (in Schulen der Pädagogik), Plattformen, Geräten, Prozessen, Support und Kosten langfristig tragfähig ist.

Unterscheiden Sie Gerätewechsel und Plattformwechsel. Hardware lässt sich vergleichsweise einfacher ersetzen. Eine über Jahre etablierte Plattform umfasst dagegen Arbeitsweisen, Unterrichts- oder Arbeitsmaterialien, Benutzerkonten, Prozesse, Know-how und Supportstrukturen. Eine Standardisierung, die eine Plattform ablöst, ist deshalb eine organisatorische Entscheidung, nicht nur eine technische. Für die Entscheidungsgrundlage empfehle ich: bestehende Lösungen und die Argumente der Beteiligten strukturiert aufnehmen; fachliche, in Schulen pädagogische, und betriebliche Vor- und Nachteile offenlegen; Kosten, Lebensdauer und Wiederverwendung der Geräte einbeziehen; den Supportaufwand für eine oder mehrere Plattformen vergleichen; prüfen, welche Unterschiede berechtigt sind, etwa nach Stufe oder Aufgabe, und welche nur historisch gewachsen; und Erfahrungen vergleichbarer Organisationen einholen. Ein Beispiel: In den Schulen einer Gemeinde im Kanton Bern arbeiten Unter- und Oberstufe mit unterschiedlichen Geräte- und Plattformstrategien. Das Projekt lief im Oktober 2026 noch (Stand der Fallstudie); eine endgültige Entscheidung war bewusst noch nicht getroffen. Das Beispiel zeigt ein Vorgehen, kein Ergebnis.

Nicht zwingend im Vertrieb. Ein Problem, das sich im Umsatz zeigt, kann früher entstanden sein: in einem unscharf verstandenen Kundenproblem, einer nicht stabil lieferbaren Leistung, einem Angebot, das niemand gleich erklärt, oder einer fehlenden Qualifizierung. Ich empfehle, die Ursache Schritt für Schritt rückwärts zu suchen, bevor Sie Personen oder Vertriebsziele ändern.

Das Go-to-Market-Steuerungsmodell von Hosang Consulting ist ausdrücklich dafür gedacht, Probleme dort zu suchen, wo sie entstehen, und nicht dort, wo sie sichtbar werden, etwa Umsatzprobleme im Vertrieb. Daraus lässt sich eine Prüfreihenfolge ableiten, die vom Abschluss rückwärts zum Problemverständnis führt. Prüfen Sie der Reihe nach: Werden Verkaufschancen auf qualifizierter Grundlage geführt, oder beruht der Forecast auf Hoffnung? Gibt es schriftliche Kriterien, wann ein Kontakt an den Verkauf übergeben wird, und werden Disqualifizierungen begründet? Ist definiert, was ein guter Lead ist, und kommt genügend passende Nachfrage? Wurde das Angebot in echten Gesprächen mit Zielkunden geprüft und danach bewusst fokussiert? Erklären Marketing, Business Development und Vertrieb das Angebot gleich, mit Nutzenversprechen, Scope und Preislogik? Ist die Leistung stabil lieferbar? Ist klar, welches Problem für wen gelöst wird und wer nicht zur Zielgruppe gehört? Die erste Frage, die Sie ehrlich mit Nein beantworten, ist ein guter Ausgangspunkt. Werten Sie zudem verlorene Abschlüsse aus: Im Modell ist ein Lost oder eine No-Decision ohne Erkenntnis ein Systemfehler; Phase 7 endet deshalb mit einer dokumentierten Begründung. Solche Fälle können zeigen, wo Erwartung und Realität auseinanderlaufen. Prüfen Sie auch, ob der Vertrieb Aufgaben trägt, die im Modell nicht seine sind: den Markt oder das Problem erst finden, Leads selbst qualifizieren oder das Angebot improvisieren. Und prüfen Sie die Erwartung: Wer in einer frühen Phase bereits Pipeline und Forecast erwartet, stellt eine Erwartung, die diese Phase nicht erfüllen kann.

Nicht unbedingt. Nach dem Go-to-Market-Steuerungsmodell von Hosang Consulting helfen mehr Leads erst, wenn feststeht, was ein guter Lead ist, das Angebot am Markt geprüft ist und genug Kapazität besteht, die Leads zu qualifizieren. Sonst steigt vor allem der Aufwand.

Im Go-to-Market-Steuerungsmodell von Hosang Consulting ist ein Lead ein identifizierter, aber noch nicht qualifizierter Kontakt; er sagt noch nichts über Bedarf oder Kaufabsicht aus. «Mehr Leads», ohne dass definiert ist, was ein guter Lead ist, nennt das Modell ein typisches Fehlbild. Systematische Leadgenerierung setzt im Modell voraus, dass die Nachfragevalidierung mit der Entscheidung abgeschlossen ist, das Angebot zu fokussieren, und dass der Angebotskern stabil ist; ohne Nachfragevalidierung ist Leadgenerierung blind. Marketing soll zudem keine Schwächen im Angebot oder im Vertrieb ausgleichen, und Qualität geht vor Menge. Als weiteres Fehlbild nennt das Modell eine Flut von Leads, die auf zu wenig Kapazität im Business Development trifft. Praktisch empfehle ich: Kriterien für einen qualifizierten Lead festlegen, etwa Passung zum Zielkundenprofil, eine relevante Rolle, ein gezeigtes aktives Interesse und eine mögliche Kontaktaufnahme; die konkreten Kriterien legt jedes Unternehmen für sein Angebot selbst fest. Messen Sie dann je Kanal, welcher Anteil der Leads tatsächlich qualifiziert wird. Bleibt dieser Anteil tief, lohnt sich der Blick auf Angebot und Zielkundenprofil, bevor Sie die Menge erhöhen. Statt «Wir brauchen mehr Leads» hilft im Gespräch die Frage: «Wie viele unserer Leads der letzten Monate passten zu unserem Zielkundenprofil, und was ist mit ihnen geschehen?»

Das hängt von der Phase und ihrem Reifegrad ab, nicht in erster Linie von der Person, die sie verantwortet. Im Go-to-Market-Steuerungsmodell von Hosang Consulting sind in frühen Phasen Erkenntnisse und geschärfte Hypothesen realistisch, Pipeline, Forecast und Abschlüsse erst in späteren Phasen.

Das Modell nennt für jede Phase, was realistisch ist und was nicht. Problem- und Marktverständnis: geschärfte Hypothesen und klar eingegrenzte Zielmärkte, nicht Pipeline oder Forecast. Produktdefinition: Leistung und Umfang testbar machen, nicht skalierbare Leads. Angebotsdesign und Positionierung: klarer Nutzen, klare Zielgruppe und klare Botschaften, nicht hohe Abschlussquoten ohne Nachweis. Nachfragevalidierung: Gespräche, Erkenntnisse und erste Pilotprojekte, keine stabile Abschlussquote. Systematische Leadgenerierung: wiederholbare Leadquellen, nicht dass Marketing allein Umsatz macht. Sales Development: Qualifizierung, Termine und Sales Qualified Leads, nicht Closing oder Vertragsverhandlungen. Sales und Closing: Abschlüsse, Verhandlungen und ein belastbarer Forecast, nicht dass der Vertrieb erst den Markt findet. Delivery und Customer Success: Kundenwert, Kundenbindung und Erweiterung, nicht der Ersatz für die Gewinnung neuer Nachfrage. Feedback und Optimierung: Lernschleifen und laufende Optimierung, nicht ein einmal definierter Prozess. Zusätzlich beurteilt das Modell jede Phase einzeln auf fünf Reifegradstufen: 0 Hypothesen (Annahmen, noch keine belastbaren Signale), 1 erste Signale (einzelne Erfolge, stark manuell), 2 wiederholbar (wiederkehrende Muster, definiertes Zielkundenprofil, einfache Playbooks), 3 messbar (Kennzahlen, saubere Übergaben, gepflegte Kundendaten) und 4 skalierbar (Wachstum ohne linearen Personalaufbau). Ein Unternehmen kann so im Angebotsdesign bereits wiederholbar arbeiten und in der Leadgenerierung noch bei Hypothesen stehen. Die Beispiele für die Stufen 3 und 4 beziehen sich vor allem auf die Phasen 5 bis 8. Ich empfehle, je Phase festzuhalten, welche Stufe Sie heute mit Belegen zeigen können, nicht welche Sie sich wünschen. Ziele und Erwartungen an Personen lassen sich dann aus dieser Einschätzung ableiten, statt umgekehrt.

Wenn die Ergebnisse der Phase vorliegen und der Übergang bewusst entschieden wird, nicht wenn eine Frist abgelaufen ist. Im Go-to-Market-Steuerungsmodell von Hosang Consulting hat jede Phase eine Voraussetzung, zentrale Fragen, die belastbar beantwortet sein müssen, erwartete Ergebnisse und beobachtbare Kriterien, an denen sich zeigt, dass sie trägt.

Das Modell stellt beim Übergang eine einfache Frage: Liegen die Ergebnisse vor, oder wird eine Phase übersprungen, deren Lücke später teuer wird? Jede Phasenseite nennt dazu die zentralen Fragen, die belastbar beantwortet sein müssen, und die Anzeichen, dass die Phase trägt; für die Nachfragevalidierung sind die Fragen in der Antwort zur Reife eines Angebots für den Markttest zusammengefasst. Getragen ist die Nachfragevalidierung zum Beispiel, wenn genug qualifizierte Gespräche Muster erkennen lassen und ein erkennbarer Teil zu einem sinnvollen nächsten Schritt führt. Die Übergänge im Überblick: Phase 2 beginnt mit einem validierten Problem-Statement und einem klaren Zielkundenprofil (ICP); Phase 3 mit einer klaren, lieferfähigen Produktdefinition; Phase 4 mit einem einheitlichen, erklärbaren Angebot und dem bewussten Entscheid, es im Markt zu prüfen; Phase 5 mit dem Entscheid, das Angebot zu fokussieren, klar identifizierten Segmenten mit Resonanz und einem stabilen Angebotskern; Phase 6 mit definierten Kriterien für Marketing Qualified Leads (MQL) und Übergaberegeln; Phase 7 mit einem übergebenen Sales Qualified Lead (SQL) mit dokumentierter Qualifizierung; Phase 8 mit dem Vertrag oder Auftrag und einer klaren Leistungs- und Erwartungsgrundlage. Phase 9 setzt abgeschlossene Zyklen aus den Phasen 4 bis 8 voraus und läuft danach regelmässig. Besonders deutlich ist der Übergang nach der Nachfragevalidierung: Am Ende steht die Entscheidung fokussieren, anpassen oder stoppen, getroffen von der Person, die das Angebot verantwortet. Skaliert wird nur nach «fokussieren»; wer anpasst, kehrt ins Angebotsdesign zurück. Ab Phase 5 laufen die Phasen dauerhaft nebeneinander; ihre Voraussetzungen beschreiben dann, wann eine Phase eingerichtet ist, nicht wann ein einzelner Lead weitergeht. Ich empfehle, jede Übergangsentscheidung kurz schriftlich festzuhalten: wer entschieden hat, auf welcher Grundlage und welche Lücken bewusst in Kauf genommen werden. So lässt sich später nachvollziehen, warum eine Phase begonnen wurde.

Im Go-to-Market-Steuerungsmodell von Hosang Consulting ist ein Angebot reif für den Markttest, wenn es einheitlich und erklärbar beschrieben ist, mit Zielkunden, Nutzenversprechen, Scope und Preislogik, und wenn bewusst entschieden wurde, es aktiv im Markt zu prüfen. Geprüft wird dann das Angebot, nicht die Leistungsfähigkeit des Vertriebs.

Im Go-to-Market-Steuerungsmodell von Hosang Consulting ist das Angebotsdesign abgeschlossen, wenn Folgendes vorliegt: eine extern verständliche Angebotsbeschreibung, ein am Ergebnis orientiertes Nutzenversprechen, ein klarer Scope und Nicht-Scope, ein Preisrahmen oder eine Preissystematik, eine einheitliche Argumentations- und Entscheidungslogik und erstes Material für die Validierung, etwa ein Onepager oder ein kurzer Pitch. Ein einfacher Test: Marketing, Business Development und Vertrieb erklären das Angebot gleich, und Aussenstehende verstehen es ohne zusätzliche Interpretation. In der Nachfragevalidierung wird geprüft, ob das Angebot in echten Gesprächen mit echten Zielkunden reale Nachfrage erzeugt: ob es ohne lange Erklärung verstanden wird, ob das Problem als relevant und dringend gilt, ob echtes Interesse an nächsten Schritten besteht, welche Einwände wiederkehren und welche Segmente reagieren. Bewusst nicht dazu gehören Umsatzziele, Forecasts und Annahmen zur Skalierung. Die Qualität der Gespräche zählt mehr als ihre Anzahl, und die Erkenntnisse fliessen verbindlich ins Angebot zurück. Die Phase endet mit dokumentierten Erkenntnissen, klar identifizierten Segmenten mit Resonanz, bestätigten oder widerlegten Annahmen und einer bewussten Entscheidung: fokussieren, anpassen oder stoppen. Leadgenerierung und Vertrieb werden erst nach «fokussieren» skaliert. Als praktischen Reifetest empfehle ich: Lassen Sie je eine Person aus Marketing, Business Development und Vertrieb das Angebot unabhängig voneinander in drei Sätzen schriftlich erklären und vergleichen Sie Zielkunden, Nutzen, Scope und Preislogik. Wo die Texte auseinandergehen, ist das Angebot noch nicht reif. Legen Sie zudem vor den ersten Gesprächen fest, welches Gesprächsergebnis als positives Signal gilt, damit Sie danach nicht nachträglich deuten. Die typischen Fehlbilder dieser Phase stehen auf der Modellseite zur Nachfragevalidierung.

Das beantwortet ein trennscharfes Zielkundenprofil, im Go-to-Market-Steuerungsmodell von Hosang Consulting Ideal Customer Profile (ICP) genannt: die klar abgegrenzte Gruppe, für die Ihr Angebot nachweislich relevant, lieferbar und wirtschaftlich sinnvoll ist, mit ebenso klaren Ausschlusskriterien.

Im Modell ist das ICP keine Marketing-Zielgruppe, keine Wunschliste, keine breite Persona, kein Umsatzziel und keine Garantie für Kaufbereitschaft, sondern eine Entscheidungsgrundlage. Es wirkt als Filter über mehrere Phasen: bei der Abgrenzung relevanter Probleme, beim Schärfen von Angebot und Positionierung, bei der Definition qualifizierter Leads, bei der Qualifizierung und beim Fokus im Verkauf. Ohne klares ICP ist jede Qualifizierung beliebig. Erarbeitet wird es im Modell in Phase 1: ausgehend von Annahmen und bestehenden Kundenkontakten über qualitative Gespräche mit potenziellen Kunden, eine Segmentierung nach Branche, Rolle und Kontext und die Verdichtung zu Problemclustern. Typische Dimensionen sind Branche oder Marktsegment, Unternehmensgrösse und Reife, die Rollen im Buying Center, die typische Ausgangssituation, technische, organisatorische oder regulatorische Rahmenbedingungen sowie Ausschlusskriterien. Entscheidend ist die Trennschärfe, nicht dass alle Dimensionen gleich stark ausgeprägt sind. Ein praktischer Test, den ich empfehle: Können zwei Personen in Ihrem Unternehmen anhand des Profils unabhängig voneinander entscheiden, ob ein konkreter Interessent dazugehört? Formulieren Sie die Ausschlüsse ausdrücklich, etwa in der Form «nicht für Unternehmen, die …», damit Marketing und Vertrieb sie gleich anwenden. Endgültig ist das Profil nicht. Im Modell wird es laufend geschärft, vor allem durch die Nachfragevalidierung und durch die Auswertung realer Erfahrungen in der Feedbackphase.

Im Go-to-Market-Steuerungsmodell von Hosang Consulting gilt: Ist die gesamtverantwortliche Funktion einer Phase nicht eigens besetzt, übernimmt die Geschäftsleitung die Gesamtverantwortung, und zwar an Stelle dieser Funktion, nicht zusätzlich. In gründergeführten Unternehmen ist das häufig die Gründerin oder der Gründer.

Die Rollen im Modell bezeichnen Funktionen, keine Stellen; eine Person kann mehrere Rollen gleichzeitig ausüben. Entscheidend ist, dass je Phase klar ist, wer das Ergebnis verantwortet, wer die Arbeit treibt, wer fachlich einbezogen und wer informiert wird. Das Ergebnis verantwortet je Phase genau eine Funktion. Unklare Verantwortung führt nach dem Modell zu Erwartungskonflikten, Entscheidungsstau oder stillschweigend übernommener Verantwortung. Die Gesamtverantwortung ist im Modell so verteilt: Phasen 1 und 9 Geschäftsleitung; Phase 2 Produktverantwortung; Phasen 3 und 4 die Person, die das Angebot verantwortet; Phase 5 die für Marketing gesamtverantwortliche Person; Phasen 6 und 7 die für Sales gesamtverantwortliche Person, in Phase 7 einschliesslich Umsatzverantwortung; Phase 8 die Delivery-Leitung. Fehlt eine dieser Funktionen, rückt die Geschäftsleitung an ihre Stelle. Für kleine Unternehmen sind zwei weitere Regeln des Modells hilfreich: Gibt es kein eigenes Sales Development, treibt Business Development die Qualifizierung, ohne die Gesamtverantwortung zu übernehmen. Und wo dieselbe Person qualifiziert und abschliesst, werden die Kriterien für einen Sales Qualified Lead (SQL) schriftlich festgehalten und die Einstufung dokumentiert. Ich empfehle eine einseitige Übersicht mit einer Zeile je Phase und einem Namen je Verantwortung. Steht derselbe Name in fast allen Zeilen, ist das kein Fehler, aber ein Hinweis, Kapazität und Prioritäten bewusst zu planen.

Im Go-to-Market-Steuerungsmodell von Hosang Consulting sind verlorene Abschlüsse und Fälle ohne Entscheidung kein Misserfolg, sondern eine zentrale Lernquelle: Sie zeigen, wo Erwartung und Realität auseinanderlaufen. Ein Lost oder No Decision ohne Erkenntnis gilt dort als Systemfehler.

Im Modell endet der Verkauf entweder mit einem Abschluss oder mit einem dokumentiert begründeten Lost oder No Decision. Diese Begründungen fliessen zusammen mit Disqualifizierungsgründen, begründeten Rückweisungen qualifizierter Leads und Erfahrungen aus der Lieferung in die Phase Feedback und Optimierung. Dort werden in regelmässigen Reviews, etwa monatlich oder quartalsweise, Muster statt Einzelfälle betrachtet. Angepasst wird das System, nicht das Symptom. Praktisch empfehle ich: den Grund unmittelbar nach dem Entscheid festhalten, wenn möglich in den Worten der Kundin oder des Kunden und getrennt von der eigenen Einschätzung; unterscheiden, ob gegen Ihr Angebot, gegen das Vorhaben überhaupt oder gar nicht entschieden wurde; um ein kurzes Rückmeldegespräch ohne Verkaufsabsicht bitten; und die Gründe in einer einfachen Liste sammeln, damit Muster über mehrere Fälle sichtbar werden. Die Erkenntnisse können nach dem Modell an verschiedenen Stellen ansetzen: am Zielkundenprofil, an Leistung, Nutzenversprechen und Scope, an den Kriterien für die Qualifizierung von Leads oder an den Erwartungen, die im Verkauf geweckt werden. Jedes Review endet mit einer Entscheidung: optimieren, fokussieren oder neu ausrichten. Typische Fehlbilder, die das Modell nennt: Schuldzuweisungen statt Ursachenanalyse, Einzelmeinungen, die Muster überlagern, und Erkenntnisse, die dokumentiert, aber nicht umgesetzt werden.

Es ist eine eigene Methode von Hosang Consulting: ein gemeinsames mentales Modell in neun Phasen für den Weg von der Produktidee bis zum realisierten Kundenwert. Es soll sichtbar machen, wo ein Vorhaben steht, was in dieser Phase realistisch erwartet werden kann, wer welche Verantwortung trägt und wo die Ursache liegt, wenn etwas nicht funktioniert.

Die neun Phasen sind in drei Bereiche gegliedert. Erkenntnis und Aufbau: 1 Problem- und Marktverständnis, 2 Produktdefinition, 3 Angebotsdesign und Positionierung, 4 Nachfragevalidierung. System und Umsatz: 5 Systematische Leadgenerierung, 6 Sales Development, 7 Sales und Closing, 8 Delivery und Customer Success. Feedback und Lernen: 9 Feedback und Optimierung. Umsatz ist im Modell ein Ergebnis späterer Phasen, nicht der methodische Kern. Angewendet wird das Modell je Vorhaben, also je Angebot und Zielsegment, nicht auf das ganze Unternehmen. Ab Phase 5 laufen die Phasen dauerhaft nebeneinander; ihre Voraussetzungen beschreiben, wann eine Phase eingerichtet ist, nicht wann ein einzelner Lead oder Auftrag weitergeht. Auch der Reifegrad wird je Phase beurteilt. Das Modell ist ausdrücklich kein Methodenhandbuch und keine lineare Checkliste: Erkenntnisse aus späteren Phasen fliessen in frühere zurück. Zur Einordnung: Das Modell ist auf der Website als eigene Methode von Hosang Consulting ausgewiesen. Die Modellseiten nennen keine Studien oder externen Quellen, auf die es sich stützt. Die Rollen orientieren sich an gängigen Begriffen aus der Praxis, sind aber funktionsbezogen beschrieben, und Begriffe wie Ideal Customer Profile (ICP), Marketing Qualified Lead (MQL) oder Sales Qualified Lead (SQL) haben im Modell eine festgelegte Bedeutung. Wer diese Begriffe aus anderen Quellen kennt, sollte die Definitionen im Glossar des Modells vergleichen, bevor er sie gleichsetzt. Für den Einstieg reichen zwei Fragen: In welcher Phase steht unser Vorhaben tatsächlich? Und welche Ergebnisse früherer Phasen fehlen noch? Für die Anwendung empfiehlt es sich, zuerst den tatsächlichen Entwicklungsstand und die grössten offenen Fragen festzustellen, statt die Phasen starr der Reihe nach abzuarbeiten.

Wenn Nachfrage, Wettbewerb und Kompetenzen passen, lohnt es sich, die Ursache zuerst intern zu suchen: Ist geklärt, wer das Geschäftsfeld verantwortet, welche Ressourcen tatsächlich verfügbar sind und ob die Organisation die nötigen Veränderungen mitträgt? Eine gute Marktchance nützt wenig, wenn intern nicht entschieden wird, ob und wie sie ergriffen wird.

Eine Marktanalyse zeigt, ob Nachfrage, Wettbewerb und eigene Kompetenzen zusammenpassen. Sie zeigt nicht, ob Ihre Organisation die Chance praktisch nutzen kann. Ich habe Unternehmen begleitet, die exzellente Marktanalysen besassen und trotzdem scheiterten, nicht weil die Analyse falsch war, sondern weil die internen Voraussetzungen fehlten. Eine gute Marktanalyse ist deshalb notwendig, reicht allein aber nicht aus. Schauen Sie im Rückblick auf den Start und auf heute: Wurde beim Start eine verantwortliche Person mit Entscheidungsbefugnis bestimmt, und trägt sie das Geschäftsfeld heute noch, nicht nur nebenbei? Wurden die damals zugesagten Personen, Budgets und Zeiten tatsächlich bereitgestellt? Mussten Entscheidungen auf Wege warten, die für ein Geschäft, das noch lernt, zu langsam sind? Wurden Rollen, Prozesse und Strukturen für das Neue angepasst, oder lief es im alten Rahmen mit? Für die Prüfung vor einem neuen Vorhaben eignet sich die Frage, woran Sie Ihre Bereitschaft für eine Marktchance erkennen. Eine weitere Ursache kann zwischen Markt und Organisation liegen. Das Go-to-Market-Steuerungsmodell von Hosang Consulting geht davon aus, dass ein Problem, das sich erst im Vertrieb oder im Umsatz zeigt, oft früher entstanden ist: in einem unscharf verstandenen Kundenproblem, einer Leistung, die nicht stabil lieferbar ist, oder einem Angebot, das intern niemand gleich erklärt. Fragen Sie deshalb auch, ob Zielkunden, Nutzenversprechen und Preislogik festgelegt und in echten Gesprächen geprüft wurden. Halten Sie die Befunde kurz schriftlich fest und führen Sie eine bewusste Entscheidung herbei: weiterführen, sobald die fehlenden Voraussetzungen geklärt sind, neu ausrichten oder beenden. Auch ein begründetes Nein kann ein wertvolles Ergebnis sein.

Bereitschaft zeigt sich nicht in Begeisterung, sondern in prüfbaren Voraussetzungen: geklärte Verantwortung, ausreichend schnelle Entscheidungswege, verfügbare Ressourcen und die Bereitschaft, bestehende Strukturen anzupassen. Ich empfehle, diese Voraussetzungen zu prüfen, bevor Sie Optionen ausarbeiten oder investieren.

Neues Geschäft erfordert neue Rollen, neue Prozesse und neue Risiken. Veränderungsbereitschaft zeigt sich deshalb in beobachtbaren Fähigkeiten: Selbstreflexion, Offenheit gegenüber Fakten, Ehrlichkeit über Grenzen und der Bereitschaft, Verantwortung zu übernehmen. Ich beginne Business Development nicht mit der Annahme, dass diese Bereitschaft vorhanden ist, sondern prüfe sie. Hilfreiche Prüffragen sind: Ist ausreichend verstanden, warum die Veränderung nötig ist und was danach besser sein soll? Sind Rollen und Verantwortlichkeiten geklärt, und gibt es Menschen, die das Vorhaben tragen? Sind die Entscheidungswege schnell genug? Ist die Bereitschaft vorhanden, bestehende Strukturen anzupassen? Können wir ehrlich sagen, was wir noch nicht wissen? Danach folgt das Verstehen der Chance selbst: Was sind Fakten, was Annahmen? Welche Interessen und Abhängigkeiten bestehen? Was wissen wir nicht? Erst wenn diese Grundlage belastbar ist, entwickle ich Optionen, und erst wenn die Optionen verstanden und bewertet sind, entsteht eine Entscheidung. Diese Reihenfolge verhindert, dass ein Plan auf ungeprüften Annahmen aufbaut. Für das Gespräch in der Geschäftsleitung eignet sich eine einfache Frage: «Wer von uns trägt diese Chance intern, und was lassen wir dafür bleiben?» Wenn darauf keine klare Antwort kommt, ist das ein Hinweis, zuerst die Voraussetzungen zu klären.

Ich empfehle, die Erkenntnisse der Studien zusammenzuführen und zu priorisierten Anwendungsfällen, umsetzbaren Projektbausteinen und einem Zielbild für die schrittweise Einführung zu verdichten. Ein Pilot prüft dann einen ausgewählten Anwendungsfall unter realen Bedingungen, bevor Partnerschaften verbindlich werden.

Studien können folgenlos bleiben, wenn jede eine eigene Perspektive bearbeitet, etwa Regulatorik, Technik, Prozesse oder Wirtschaftlichkeit, und niemand die Ergebnisse zu einer gemeinsamen Entscheidungsgrundlage verbindet. Als ersten Schritt empfehle ich deshalb keine weitere Studie, sondern eine Übersicht, die die Anforderungen aus allen Perspektiven nebeneinanderstellt und Widersprüche sichtbar macht. Ich empfehle danach diese Reihenfolge: Anwendungsfälle nach Nutzen, Machbarkeit und Abhängigkeiten priorisieren; ein Zielbild für die schrittweise Einführung festhalten; einen Anwendungsfall als Pilot mit einer klaren Prüffrage, einer verantwortlichen Person und vorab vereinbarten Abbruchkriterien definieren; mögliche Partner früh einbeziehen und Rollen sowie wirtschaftliche Beteiligung klären; die Übergabe an die Organisation vorbereiten, die später einführt und betreibt. Ein veröffentlichtes Fallbeispiel von Hosang Consulting zeigt diesen Weg: Für eine grosse Organisation mit dezentralen Kundenzugängen wurden Studien-, Strukturierungs- und Umsetzungsphase für neue Finanzservices zu einem durchgängigen Vorgehen verbunden, von Machbarkeits- und Integrationsstudien über priorisierte Anwendungsfälle und ein Zielbild bis zur Leitung eines Pilotvorhabens, zur Unterstützung bei der Partnergewinnung und zur Übergabe an die Einführungsorganisation. Eine Frage, die den Pilot schärft: «Welche eine Frage soll der Pilot beantworten, und was entscheiden wir, wenn die Antwort Nein lautet?»

In echten Gesprächen und Anwendungstests mit Zielkunden, auf der Grundlage eines konkreten Angebots mit Preisrahmen. Ich empfehle, Zusagen höher zu gewichten als Meinungen: Ein vereinbarter nächster Schritt, ein bezahlter Pilot oder eine schriftliche Absichtserklärung sagt mehr als ein «Das klingt interessant».

Prüfen Sie zuerst den Bedarf, noch ohne Lösung: Welches konkrete Problem hat der Kunde, in welcher Situation tritt es auf, welche Auswirkungen hat es auf Kosten, Risiko, Zeit oder Belastung, und wer entscheidet über einen Kauf? Diese Fragen stellt das Go-to-Market-Steuerungsmodell von Hosang Consulting in Phase 1, dem Problem- und Marktverständnis. Qualitative Gespräche mit potenziellen Kunden zeigen, ob dieselben Schmerzpunkte wiederholt auftauchen. Ich empfehle, die Zahlungsbereitschaft an einem konkreten Angebot mit Nutzenversprechen, Scope und Preisrahmen zu prüfen; im Modell entsteht dieser Preisrahmen in Phase 3. Erste Hinweise, etwa was das Problem heute kostet, lassen sich schon in den Gesprächen zum Bedarf sammeln. In der anschliessenden Nachfragevalidierung (Phase 4) sind nach dem Modell Gespräche, Erkenntnisse und erste Pilotprojekte realistisch, keine stabile Abschlussquote; welche Fragen dort geprüft werden, beschreibt die Frage, wann ein Angebot reif für den Markttest ist. Praktisch empfehle ich: vorab festlegen, was als positives Signal gilt; nach den heutigen Kosten des Problems und der heutigen Lösung fragen; den Preisrahmen offen nennen und Einwände wörtlich festhalten; einen verbindlichen nächsten Schritt anbieten, etwa einen bezahlten Pilot; Ergebnisse nach Segmenten auswerten und am Ende bewusst entscheiden, ob Sie fokussieren, anpassen oder stoppen. Ein veröffentlichtes Fallbeispiel von Hosang Consulting zeigt den Weg über reale Anwendungstests: Für eine Organisation, die neue Dienstleistungen direkt am Kundenstandort anbieten wollte, wurden mehrere Anwendungsszenarien und Proofs of Concept entwickelt und Bedarf, Nutzbarkeit und Zahlungsbereitschaft untersucht. Daraus entstanden validierte Anwendungsszenarien und Erkenntnisse zur Zahlungsbereitschaft.

Das hängt davon ab, welche Fähigkeiten Ihr Angebot unterscheiden, welche Ihnen fehlen und ob Sie Zusammenarbeit, Verantwortung und wirtschaftliche Beteiligung mit Partnern verbindlich regeln können. Ein veröffentlichtes Fallbeispiel von Hosang Consulting zeigt: Ein Partnernetzwerk trägt erst mit einem gemeinsamen Leistungsmodell und klaren Rollen; eine Liste von Partnern reicht nicht.

Ich empfehle, diese Kriterien abzuwägen: Für die eigene Entwicklung spricht, wenn die Fähigkeit Ihr Angebot unterscheidet, Sie sie dauerhaft brauchen und die Kontrolle über Qualität, Daten oder Kundenzugang wichtig ist. Für Partner spricht, wenn die Fähigkeit spezialisiert ist, nur projektweise gebraucht wird oder intern zu langsam oder zu teuer aufzubauen wäre. Die Antwort kann auch gemischt sein: den Kern selbst, Ergänzungen über Partner. Bevor Sie sich für ein Netzwerk entscheiden, sollten diese Punkte geklärt sein: ein gemeinsames Leistungs- und Kooperationsmodell; wer gegenüber dem Kunden verantwortet; wie Marktzugang und Projektanbahnung organisiert sind; wie die wirtschaftliche Beteiligung geregelt ist; und was geschieht, wenn ein Partner ausfällt. Ein veröffentlichtes Fallbeispiel von Hosang Consulting beschreibt den Aufbau eines IoT-Ökosystems: Die nötigen Fähigkeiten waren auf verschiedene Unternehmen, Forschungspartner und Fachpersonen verteilt, und es fehlten gemeinsame Strukturen für Zusammenarbeit, Marktzugang, Verantwortung und wirtschaftliche Beteiligung. Entwickelt wurden ein Geschäfts- und Kooperationsmodell entlang der Wertschöpfungskette; Partner wurden gewonnen, erste gemeinsame Kundenprojekte begleitet und die zentralen Annahmen iterativ an realen Projekten überprüft. Eine Frage für die Entscheidung: «Wenn dieser Partner morgen wegfällt, was können wir unseren Kunden dann noch zusagen?» Lautet die Antwort «nichts», gehört die Fähigkeit entweder ins eigene Haus oder in eine verbindlichere Vereinbarung.

Hängt die Umsetzung von einem einzigen Partner ab, kann das ganze Vorhaben scheitern, auch wenn Idee und Prozessmodell tragen. Deshalb sollten Zusage, wirtschaftliche Interessen und Alternativen dieses Partners früh und verbindlich geklärt werden, nicht erst kurz vor dem Start.

Ein veröffentlichtes Fallbeispiel von Hosang Consulting zeigt das offen: Während der Pandemie entwickelte ein interdisziplinäres Team, in dem Hosang Consulting mitarbeitete, ein Testangebot für Familien mit einem Pooling-Modell fachlich, prozessual und wirtschaftlich weit. Ein konkretes Angebot war für die Einreichung vorbereitet. Kurz davor zog sich der vorgesehene Laborpartner überraschend zurück. Ohne ihn war keine Umsetzung möglich; das Angebot wurde nicht eingereicht und nie im Markt eingeführt. Vorbeugen lässt sich mit einigen Schritten: früh benennen, ohne welchen Partner nichts funktioniert; klären, welchen eigenen wirtschaftlichen Nutzen dieser Partner aus dem Vorhaben zieht; die Zusage in eine verbindliche Form bringen, bevor Sie grössere Mittel einsetzen; mindestens eine Alternative im Gespräch halten oder wissen, was ein Wechsel kosten würde; und einen Entscheidungspunkt festlegen: Liegt bis dahin keine verbindliche Zusage vor, wird das Vorhaben angepasst oder gestoppt. Eine direkte Frage an den Partner hilft, verdeckte Risiken anzusprechen: «Was müsste geschehen, damit Sie sich aus dem Vorhaben zurückziehen?» Die Antwort zeigt, welche Bedingungen Sie absichern sollten.

Ich empfehle, die Unterlagen nicht von der Technik her aufzubauen, sondern von dem, was Entscheidungsträger ohne technisches Vorwissen zuerst verstehen müssen: welches Problem gelöst wird, wo die Technologie angewendet werden kann und warum sie strategisch relevant ist. Technische Details stützen diese Aussagen, sie ersetzen sie nicht; Business Case, Finanzplanung und Risiken bleiben eigene Prüfpunkte der Investoren.

Im veröffentlichten Fallbeispiel halfen eine klare Struktur, eine gute visuelle Führung und begleitendes Material, das Potenzial vermittelt, ohne das Publikum mit technischem Detail zu überladen. Ich empfehle zudem konkrete Anwendungsfälle; sie machen greifbar, was eine Funktionsbeschreibung abstrakt lässt. Eine einfache Prüfung vor dem Gespräch: Kann eine Person ohne technisches Vorwissen nach Durchsicht der Unterlagen in eigenen Worten sagen, welches Problem gelöst wird, für wen und warum jetzt? Wenn nicht, lohnt es sich, zuerst die Struktur zu überarbeiten, bevor weiteres Detail ergänzt wird. Bei dieser Aufbereitung kann ich unterstützen. In einem veröffentlichten Fallbeispiel habe ich als Teil eines Beratungsteams Unterlagen für die Investorenansprache eines Waste-to-Hydrogen-Projekts aufbereitet: Präsentationsdokumente vorbereitet und geschärft, an Foliendecks mitgearbeitet, komplexe Inhalte strukturiert sowie Videoschnitt und begleitendes Material beigesteuert. Meine Rolle war die Aufbereitung und Kommunikation der Unterlagen, nicht die eigenständige Erarbeitung des gesamten Business Case.

Eine Business Analyse klärt vor einer Entscheidung, welcher Bedarf tatsächlich besteht, welche Anforderungen gelten und welche Lösungswege infrage kommen. Sie ist nicht auf IT beschränkt: Auch Standortfragen, neue Geschäftsfelder, Investitionen und organisatorische Veränderungen lassen sich so strukturiert klären.

Der internationale Berufsverband IIBA beschreibt Business Analyse sinngemäss als die Praxis, Veränderung in einer Organisation zu ermöglichen, indem Bedürfnisse definiert und Lösungen empfohlen werden, die für die Anspruchsgruppen Wert schaffen. Er nennt ausdrücklich Unternehmen, Verwaltungen und Non-Profit-Organisationen. Der Kern ist also nicht die Technik, sondern die Frage, was sich ändern soll und warum. In der Praxis heisst das: mit den Beteiligten sprechen, Anforderungen und Abläufe strukturieren, Annahmen prüfen, Abhängigkeiten und Widersprüche sichtbar machen und Optionen mit ihren Vor- und Nachteilen, Risiken und wirtschaftlichen Folgen vergleichen. Typische Ergebnisse sind eine gemeinsame Beschreibung von Ausgangslage, Problem und Ziel, strukturierte Anforderungen und Prozessdarstellungen, ein Optionsvergleich, eine begründete Empfehlung oder ein Zielbild. Nicht jede Analyse braucht alle diese Ergebnisse. Sinnvoll ist eine Business Analyse vor allem, wenn eine Lösung diskutiert wird, die Beteiligten aber unterschiedliche Vorstellungen vom Bedarf haben, wenn Fachbereich und IT über Funktionen statt über das gemeinsame Ziel sprechen, wenn mehrere Optionen zur Wahl stehen oder eine Ausschreibung ansteht. Nicht nötig ist sie, wenn Ziel, Anforderungen und Lösung bereits ausreichend geklärt sind. Eine gute Faustregel: Die Analyse geht so weit, wie es für eine verantwortbare Entscheidung nötig ist, nicht weiter. Ein dokumentiertes Beispiel von Hosang Consulting ausserhalb der IT: Für ein Gastronomieunternehmen aus Graubünden werden neue Standortoptionen geprüft. Gefragt wird, ob der Standort passt, welches Betriebsmodell sinnvoll ist, welche Zielgruppen angesprochen werden und wie eine wirtschaftlich tragfähige Angebotslogik aussieht. Daraus entstehen Betriebskonzepte und Entscheidungsunterlagen. Abgrenzung: Requirements Engineering ermittelt, dokumentiert, prüft und verwaltet die Anforderungen und ist je nach Auftrag Teil einer Business Analyse. Projektmanagement organisiert und führt danach die Umsetzung eines beschlossenen Vorhabens.

Klären Sie zuerst so weit, wie es die Entscheidung verlangt: Welches Problem soll gelöst werden, für wen, und woran merken Sie, dass es gelöst ist? Gerade wenn Beteiligte das Problem unterschiedlich sehen, löst leicht das falsche Problem, wer zuerst die Technologiefrage beantwortet. Sind Ziel und Anforderungen bereits ausreichend geklärt, ist eine zusätzliche Analyse nicht automatisch nötig.

HERMES sieht in der Studie vor, zuerst zu prüfen, ob es eine neue Lösung überhaupt braucht. Erst auf Basis von Zielen und Anforderungen werden Lösungsvarianten beschrieben und nach Zielerreichung, Anforderungsabdeckung, Machbarkeit, Risiken und Nutzen bewertet. Diese Reihenfolge hilft auch ausserhalb der Bundesverwaltung: Sie verhindert, dass ein bereits vorgestelltes Produkt zum Massstab wird. Ein kurzer Selbsttest vor der Lösungswahl: Beschreiben die Beteiligten das Problem in eigenen Worten gleich? Ist klar, wer entscheidet und wer die Lösung später betreibt? Gibt es Prioritäten, falls nicht alles gleichzeitig möglich ist? Ist eine dieser Fragen offen, lohnt sich eine Klärung vor der Auswahl. Ein Beispiel: In einer Gemeinde im Kanton Bern war die Informatik über Verwaltung, Schulen und weitere Einheiten gewachsen. Statt vorschnell eine neue Lösung auszuwählen, wurde zuerst sichtbar gemacht, wie Anwendungen, Geräte, Rollen, Zuständigkeiten und Dienstleister heute zusammenspielen. Daraus entstanden ein gemeinsames Zielbild, priorisierte Handlungsfelder und ein Umsetzungsplan. Das Beispiel zeigt einen Fall, keine allgemeine Regel.

Wahrscheinlich liegt es nicht an der Qualität der Analyse, sondern daran, dass sie nicht auf eine Entscheidung ausgerichtet ist. Eine Analyse, die keine konkrete Entscheidung vorbereitet, bleibt Dokumentation, und Dokumentation allein verändert nichts.

Typische Anzeichen: Das Dokument wurde formal abgenommen, aber niemand kann sagen, welche Entscheidung es vorbereiten sollte, wer sie trifft und bis wann. Oder es enthält viele Anforderungen und Prozessmodelle, aber keine Optionen mit ihren Folgen, zwischen denen jemand wählen könnte. Was hilft: Formulieren Sie die ausstehende Entscheidung als eine Frage und benennen Sie, wer sie trifft. Ziehen Sie aus der Analyse die zwei oder drei Optionen heraus, die tatsächlich zur Wahl stehen, je mit Nutzen, Aufwand und Risiko. Kennzeichnen Sie, was belegt ist, was angenommen wird und was niemand weiss: Eine unbestätigte Zahl, die wie eine Tatsache dasteht, führt zu einer Entscheidung auf falscher Grundlage. Legen Sie schliesslich einen Termin fest, an dem entschieden wird, auch wenn die Entscheidung «zurückstellen» lautet. Manchmal liegt der Stillstand nicht an der Analyse: Ist ein Entscheid politisch heikel oder hat niemand die nötige Befugnis, ändert ein besseres Dokument wenig. Dann ist zuerst zu klären, wer entscheidet.

Eine Grundlage für die nächste Entscheidung, nicht ein möglichst vollständiges Dokument: ein gemeinsames Bild der Ausgangslage, begründete und priorisierte Anforderungen oder Optionen und eine klare Aussage, was als Nächstes zu entscheiden ist.

Das International Institute of Business Analysis (IIBA) beschreibt Business Analysis als Praxis, Veränderung zu ermöglichen, indem Bedürfnisse definiert und Lösungen empfohlen werden, die für die Beteiligten Wert schaffen. Am Ende sollte deshalb erkennbar sein, welcher Bedarf besteht und welche Lösung oder welcher nächste Schritt empfohlen wird, nicht nur, was erhoben wurde. Als Prüfkriterien empfehle ich: Erkennen Fachbereich, Informatik und Geschäftsleitung die beschriebene Ausgangslage wieder? Sind Fakten, Annahmen und offene Punkte getrennt? Sind Anforderungen begründet und priorisiert? Sind Optionen mit Vor- und Nachteilen, Risiken und wirtschaftlichen Folgen verglichen? Ist die anstehende Entscheidung benannt, mit möglichen Ausgängen wie weitergehen, anpassen, zurückstellen, stoppen oder intern weiterarbeiten? Welche Ergebnisse konkret nötig sind, hängt von dieser Entscheidung ab. Möglich sind eine gemeinsame Problembeschreibung, strukturierte Anforderungen und Prozessdarstellungen, ein Optionenvergleich, eine priorisierte Empfehlung oder ein Zielbild. Nicht jede Analyse braucht alle davon.

Vor allem, wer was entscheidet und wie künftig gearbeitet wird: Ziele, Rollen, Abläufe, Informationsflüsse und Zuständigkeiten. Ein System kann technisch eingeführt sein, ohne organisatorisch angekommen zu sein.

Nach meiner Erfahrung scheitern Digitalisierungsprojekte selten an der Technologie, häufiger an Entscheidungen, die schon vorher ungeklärt waren. Technologie wirkt dabei oft als Verstärker: Sind Rollen unklar, werden sie durch ein neues System nicht klarer. Eine kurze Prüfliste vor Konfiguration und Einführung: Welche Abläufe ändern sich, und wer hat das entschieden? Wer ist fachlich verantwortlich für das System und seine Daten? Wer entscheidet über Anpassungen und Prioritäten? Welche Daten werden übernommen, und wer bereinigt sie? Wie werden die Mitarbeitenden befähigt? Und woran erkennen Sie nach einigen Wochen, ob das System im Alltag tatsächlich genutzt wird? Sind diese Punkte geklärt, braucht es keine zusätzliche Analyse um ihrer selbst willen. Sind wesentliche Fragen offen, ist es sinnvoll, sie vor der Konfiguration zu klären.

Hosang Consulting prüft Bereitschaft anhand von sechs Dimensionen: Notwendigkeit, Zielklarheit, Verantwortung, Bereitschaft der Beteiligten, Fähigkeit sowie Ressourcen und Rahmenbedingungen. Das Ergebnis ist eine Einordnung als bereit, bedingt bereit oder noch nicht bereit, keine Punktzahl.

Die sechs Dimensionen als Fragen: Ist ausreichend verstanden, warum die Veränderung nötig oder sinnvoll ist? Ist klar genug, was danach besser oder anders sein soll? Gibt es Menschen, die die Veränderung tragen und die nötigen Entscheidungen treffen können? Wollen die relevanten Beteiligten bestehende Annahmen, Verhaltensweisen oder Strukturen überprüfen? Sind die Kompetenzen vorhanden oder realistisch aufbaubar? Stehen Zeit, Menschen, Aufmerksamkeit, Informationen und Mittel zur Verfügung? Bereitschaft zeigt sich weniger in Begeisterung als in beobachtbaren Fähigkeiten: den eigenen Standpunkt prüfen, offen sein für Fakten und andere Perspektiven, Wissen, Nichtwissen und Annahmen unterscheiden, ehrlich sein über Interessen, Risiken, Fehler und Grenzen, Verantwortung übernehmen und Zusammenhänge systemisch betrachten. «Noch nicht bereit» heisst nicht zwingend Abbruch. Die fehlenden Voraussetzungen herzustellen, kann selbst der erste Schritt sein. Bleibt die Bereitschaft dauerhaft aus, sollte das Vorgehen angepasst, pausiert oder beendet werden.

Ein Betriebskonzept sollte nachvollziehbar zeigen, was an diesem Ort für wen betrieben wird und warum es wirtschaftlich trägt. In einem veröffentlichten Gastronomie-Fallbeispiel von Hosang Consulting umfasste es Positionierung, Zielgruppen, Saisonalität, Betriebsmodell, Angebotslogik, Zusatznutzungen, Wirtschaftlichkeit und Betreiberprofil; andere Branchen brauchen andere Bausteine. Dieses Fallbeispiel zeigt auch, dass Hosang Consulting solche Konzepte samt Bewerbungsunterlagen erarbeitet.

Standortgeber und andere Entscheidungsträger erwarten nachvollziehbare Unterlagen; ohne klare Struktur bleiben Ideen schwer prüfbar. Ein Gastronomie-Fallbeispiel von Hosang Consulting umfasste diese Bausteine: Positionierung (was das Angebot an diesem Ort unterscheidet), Zielgruppen, Saisonalität (wie sich die Nachfrage über das Jahr verteilt), Betriebsmodell, Angebotslogik, Zusatznutzungen, Wirtschaftlichkeit und Betreiberprofil (wer betreibt, mit welcher Erfahrung). Vor der Bewerbung lohnen sich einige Fragen: Passt der Standort zum Betriebsmodell? Welche Zielgruppen sollen angesprochen werden? Wie sieht eine wirtschaftlich tragfähige Angebotslogik aus? Welche Rolle können Investoren oder Kapitalpartner spielen? Ich empfehle, Annahmen zu Umsatz, Kosten und Investitionen ausdrücklich als Annahmen zu kennzeichnen, damit Standortgeber sie nachvollziehen und prüfen können. Im veröffentlichten Fallbeispiel begleitet Hosang Consulting ein etabliertes Gastronomieunternehmen aus Graubünden wiederkehrend bei Wachstums- und Standortfragen. Für einen neuen Standort entstand ein vollständiges Betriebskonzept mit den genannten Bausteinen, dazu die Bewerbungsunterlagen. Aus einer Idee wurde so ein strukturiertes, prüfbares Vorhaben. Über den Ausgang einzelner Vorhaben wird bewusst nichts ausgesagt.

Vertrauliche Informationen werden ausschliesslich für den vereinbarten Mandatszweck verwendet und nur den Personen zugänglich gemacht, die sie für ihre Aufgabe benötigen.

Zu Beginn kläre ich bei Bedarf zusätzliche Anforderungen an Datenschutz, Informationssicherheit, Systeme und Dokumentation. Beim Einbezug weiterer Fachpersonen gelten dieselben vereinbarten Vertraulichkeitsanforderungen.

Technische Hilfsmittel und KI-Anwendungen werden nicht unkontrolliert mit vertraulichen Kundeninformationen gespeist. Ihr Einsatz muss zum Schutzbedarf des jeweiligen Mandats passen.

Viele meiner Mandate betreffen strategische Entscheidungen, interne Konflikte, gefährdete Projekte, organisatorische Veränderungen oder vertrauliche technologische Vorhaben.

Eine detaillierte öffentliche Darstellung könnte Rückschlüsse auf Organisationen, Personen oder geschäftliche Situationen ermöglichen. Deshalb anonymisiere ich Fallbeispiele, sofern keine ausdrückliche Freigabe für eine namentliche Veröffentlichung besteht.

Die Anonymisierung soll nicht Ergebnisse künstlich vergrössern. Sie schützt die Beteiligten und erlaubt dennoch, Ausgangslage, Vorgehen und wesentliche Erkenntnisse nachvollziehbar darzustellen.

KI kann mich bei Recherche, Strukturierung, Dokumentation, Variantenbildung und der Verarbeitung umfangreicher Informationen unterstützen.

Der Einsatz erfolgt aufgabenbezogen und unter Berücksichtigung von Vertraulichkeit, Datenschutz und fachlicher Qualität. Ergebnisse von KI-Systemen werden nicht ungeprüft als Fakten oder Entscheidungen übernommen.

KI ist fester Bestandteil meiner Arbeitsweise, aber kein Ersatz für menschliche Arbeit. Qualität entsteht aus Erfahrung, Kontext, Steuerung, Prüfung und menschlichem Urteil. Wer ein Ergebnis freigibt, trägt dafür die Verantwortung; die Prüftiefe richtet sich nach dem Risiko.

Menschen führen die entscheidenden Gespräche, beurteilen Zusammenhänge, wägen Interessen und Risiken ab und übernehmen Verantwortung für Empfehlungen und Handlungen.

Dies gilt insbesondere für Führungsentscheidungen, Konflikte, ethische Abwägungen, sensible Personalthemen und Situationen, in denen Informationen unvollständig oder widersprüchlich sind.

KI kann Hinweise, Strukturen und Entwürfe liefern. Sie kann jedoch nicht verantwortlich beurteilen, was für eine konkrete Organisation und ihre Menschen angemessen ist. Diese Verantwortung bleibt bei den beteiligten Menschen.

Ja. Ezra Luck ist ein KI-Agent (Software) von MATTLI-DIGITAL, kein Mensch. Er unterstützt mich bei Projektkoordination, CRM- und Dokumentationsarbeit sowie wiederkehrenden Marketing- und Koordinationsaufgaben.

Ezra Luck arbeitet immer unter menschlicher Führung. Entscheidungen, externe Kommunikation und fachliche Verantwortung bleiben bei den zuständigen Menschen – seine Aufgabe ist es, Informationen zusammenzuführen und den Überblick zu erhalten, nicht zu entscheiden. Eigenständige strategische oder unternehmerische Entscheidungen trifft er nicht.

Ja, als Teil der Digitalisierungsberatung. Seit 2023 begleite ich Digitalisierungsvorhaben mit KI-gestützten Prozessen und Automatisierung, und 2024 habe ich eine Low-Code- und No-Code-Abteilung im ERP- und Softwareumfeld mit aufgebaut. Technologie, Low-Code und KI sind dabei Mittel zum Zweck, nicht der Ausgangspunkt.

Am Anfang steht die Frage, was sich im Geschäft verbessern soll und welche Entscheidungen dafür offen sind. Erst danach wird beurteilt, ob Automatisierung, eine Low-Code-Lösung, KI oder eine Anpassung bestehender Systeme den grössten Nutzen bringt. Nicht jede Aufgabe braucht neue Software; oft lohnt es sich zuerst zu prüfen, was mit bestehenden Systemen möglich ist. Bei der Auswahl zählen Anforderungen, Integration, Kosten, Sicherheit, Datenschutz und der langfristige Betrieb. Ich berücksichtige internationale Plattformen wie Microsoft 365 und Power Platform ebenso wie Schweizer Lösungen, spezialisierte Anwendungen und Open-Source-Produkte und bringe bei Bedarf geeignete Fachpersonen oder Umsetzungspartner ein; Verantwortung und Zusammenarbeit werden pro Auftrag geklärt.

Ein Paket ist verteilbereit, wenn es auf der Zielplattform still installiert und deinstalliert werden kann, zuverlässig erkannt wird, Abhängigkeiten und Updates sauber regelt und im Pilot mit echten Anwendungsfällen fachlich abgenommen wurde. Welche Prüfungen im Detail nötig sind, hängt von Paketformat, Verteilwerkzeug und Betriebssystemversion ab.

Legen Sie zuerst den Kontext fest: Zielplattform und eingesetzte Versionen, Paketformat (zum Beispiel MSI, MSIX, ein Win32-Installer im .intunewin-Container oder ein macOS-Paket .pkg) und Verteilwerkzeug (zum Beispiel Microsoft Intune, Configuration Manager oder eine Geräteverwaltung für Mac). Viele Prüfpunkte gelten nur in einem dieser Kontexte. Ein Beispiel für Versionsbezug: Windows 10 hat laut Microsoft am 14. Oktober 2025 mit Version 22H2 das Supportende erreicht; LTSC-Versionen folgen eigenen Lebenszyklen, und ob Geräte über das kostenpflichtige Programm für Extended Security Updates weiter Sicherheitsupdates erhalten, ist separat zu prüfen. Technische Prüfpunkte am Beispiel einer Win32-App in Microsoft Intune, abgeleitet aus der Herstellerdokumentation: Die Installation läuft still, ohne Dialoge oder Benutzereingaben. Der Installationskontext (System oder Benutzer) ist bewusst gewählt und passt zu den Rechten der Nutzenden. Ein Deinstallationsbefehl ist hinterlegt und geprüft. Rückgabecodes für Erfolg, Fehler, Neustart und Wiederholung sind korrekt zugeordnet, das Neustartverhalten ist festgelegt. Anforderungen wie Architektur und minimale Betriebssystemversion sind gesetzt. Die Erkennungsregel (MSI-Produktcode, Datei, Registry oder Skript) erkennt die richtige Version, auch nach einem Update. Abhängigkeiten sind als eigene Pakete definiert. Bei einer neuen Version ist geklärt, ob sie die alte aktualisiert oder ersetzt und ob die alte deinstalliert werden muss. Formatspezifisch kommen weitere Punkte hinzu. MSIX-Pakete müssen signiert sein; Microsoft beschreibt saubere Deinstallation und Containerisierung, die Unterstützung beginnt mit Windows 10 Version 1709 (ältere Versionen über MSIX Core), einzelne Funktionen wie Windows-Dienste erst mit späteren Versionen. Ob sich eine bestimmte Anwendung ohne Anpassung als MSIX paketieren lässt, ist im Einzelfall zu prüfen. Für Mac verlangt Apple bei der Verteilung über eine Geräteverwaltung signierte Pakete; ob beim Entfernen alle installierten Dateien verschwinden, hängt laut Apple von der macOS-Version und einer Konfiguration vor der Installation ab. Dazu gehören fachliche und betriebliche Prüfungen: Fachpersonen testen die wichtigsten Anwendungsfälle, nicht nur, ob das Programm installiert ist. Erstinstallation, Update aus der Vorversion und Deinstallation werden getrennt geprüft, auf repräsentativen Geräten und Benutzerprofilen. Die Abnahme ist dokumentiert, eine Pilotgruppe erhält das Paket vor der breiten Verteilung, und ein Rückfallvorgehen ist beschrieben, inklusive seiner Grenzen. Ich empfehle, je Paket eine kurze Prüfakte mit Testfällen, Ergebnissen, Abweichungen und Freigabe zu führen, weil sonst bei einer späteren Störung niemand mehr belegen kann, was geprüft wurde.

Diese Verantwortungen sollten getrennt benannt werden: die technische Paketqualität beim technischen Team, die fachliche Abnahme bei der zuständigen Fachstelle, die Freigabe für den nächsten Verteilschritt bei einer vorher bestimmten Entscheidungsinstanz und das Rückfallverfahren bei Betrieb und Projekt mit klarer Auslösebefugnis. Wer das konkret ist, muss im Vorhaben festgelegt werden; eine allgemeingültige Zuordnung gibt es nicht.

Trennen Sie technische Qualität und organisatorische Steuerung. Technisch geht es darum, ob das Paket still installiert, korrekt erkannt und wieder entfernt wird und ob Abhängigkeiten und Updates geregelt sind. Organisatorisch geht es darum, wer wann welches Paket erhält, wer über den nächsten Schritt entscheidet, wie Nutzende informiert und unterstützt werden und wer bei Problemen stoppt. Vermischen sich beide Ebenen, wird ein Steuerungsproblem schnell als Paketfehler behandelt oder umgekehrt. Eine mögliche Aufteilung, die Sie an Ihre Organisation anpassen: Die Paketierung verantwortet die technische Prüfung und die Prüfakte. Fachstelle oder Applikationsverantwortliche verantworten Testfälle und fachliche Abnahme. Betrieb und Service Desk verantworten Betriebsfähigkeit, Supportvorbereitung und Übernahme. Die Projekt- oder Rollout-Leitung plant die Verteilschritte, koordiniert, kommuniziert und bereitet Entscheide vor. Eine benannte Entscheidungsinstanz, etwa ein Change- oder Release-Gremium oder der Auftraggeber, gibt jeden Verteilschritt frei und entscheidet über einen Stopp. Lieferanten tragen bei, was vertraglich vereinbart ist. Für die Freigabe zwischen Verteilschritten beschreibt Microsoft für Windows-Updates zwei Strategien: Beim «green button» gilt ein Inhalt als fehlerhaft, bis die Validierung bestanden ist, und wird aktiv freigegeben. Beim «red button» läuft die Verteilung weiter, bis jemand sie stoppt. Unabhängig von der Strategie sollte vorher feststehen, wer entscheiden darf und nach welchen Kriterien, zum Beispiel Installationsquote, Supportfälle oder Abnahme im Pilot. Pilotgruppen sollten repräsentativ sein; laut Microsoft sind IT-Abteilung und Laborgeräte dafür oft nicht geeignet. Für den Rückfall klären Sie vorab, was «zurück» technisch bedeutet, etwa Deinstallation, erneute Installation der Vorversion oder Entfernen einer Zuweisung, wer ihn auslöst und wie er geprüft wurde. In der veröffentlichten Fallstudie von Hosang Consulting zur Modernisierung öffentlicher IT-Arbeitsplätze wird als Erkenntnis festgehalten, dass Softwarebereitstellung, Qualitätssicherung, Fachabnahme, Governance und Betrieb als gemeinsamer Prozess gesteuert werden müssen. Das ist Hintergrund für diese Empfehlung, keine allgemeingültige Rollenmatrix.

Prüfen Sie zuerst, ob der Fehler reproduzierbar am Paket hängt, also mit gleichem Fehlerbild auf vergleichbaren, korrekt zugewiesenen Geräten auftritt, oder ob er dort entsteht, wo Zuweisung, Zeitplan, Kommunikation, Support oder Entscheidungswege versagt haben. Oft wirken beide zusammen; eine Ursache sollte erst nach dieser Prüfung zugewiesen werden.

Hinweise auf einen technischen Paketfehler, am Beispiel von Win32-Apps in Microsoft Intune: Die Installation endet mit einem als Fehler definierten Rückgabecode. Die Installation gelingt, aber die Erkennungsregel meldet «nicht installiert», worauf Intune die App bei erforderlicher Zuweisung erneut anbietet. Der Fehler tritt nur bei einer bestimmten Architektur, Betriebssystemversion, einem Installationskontext oder bei fehlender Abhängigkeit auf. Die Anwendung startet auch auf einem sauberen Testgerät nicht richtig. Ein Update aus der Vorversion verhält sich anders als eine Neuinstallation. Hinweise auf ein Steuerungsproblem: Geräte liegen in der falschen Gruppe oder haben keine Zuweisung. Der Pilot war nicht repräsentativ. Ein Verteilschritt wurde ohne Freigabe ausgelöst. Nutzende waren nicht vorbereitet, Neustarts fielen in Arbeitszeiten, der Service Desk hatte keine Informationen. Niemand hatte die Befugnis, zu stoppen, oder eine Abhängigkeit zu einem anderen Vorhaben war nicht abgestimmt. In solchen Fällen ist das Paket oft korrekt, aber der Rahmen nicht. Ein mögliches Vorgehen: Erfassen Sie das Fehlerbild präzise mit betroffenen Geräten, Gruppen, Versionen, Zeitpunkt, Rückgabecode und Protokollen des Verteilwerkzeugs. Reproduzieren Sie den Fehler auf einem Referenzgerät. Prüfen Sie Zuweisung und Anforderungen. Suchen Sie Muster, etwa nur ein Standort, ein Hardwaremodell oder ein Verteilschritt. Lassen Sie danach die vorher bestimmte Instanz über Stopp, Korrektur oder Weiterführung entscheiden und halten Sie Ursache und Massnahme fest. Ich empfehle, technische und organisatorische Hypothesen getrennt zu notieren, weil die Diskussion sonst schnell zur Schuldfrage zwischen Technik und Projekt wird.

Indem Sie Technik, Qualitätssicherung, Fachabnahme, Rollout-Steuerung und Betrieb als einen gemeinsamen Prozess führen und schrittweise verteilen: zuerst ein Pilot, dann grössere Gruppen, jeweils nach Freigabe. So lässt sich die Störung des Betriebs begrenzen, aber nicht ausschliessen; deshalb gehören ein bewusst akzeptiertes Restrisiko, Schutzmassnahmen und ein Rückfallvorgehen mit bekannten Grenzen dazu.

Klären Sie zuerst die Ausgangslage: Gibt es Zeitfenster ohne Betrieb oder nicht? Welche Standorte, Prozesse und Fachanwendungen sind kritisch? Welche Geräte und Applikationen sind betroffen, und welche Abhängigkeiten bestehen? In der veröffentlichten Fallstudie von Hosang Consulting zur Geräteerneuerung in einem landesweiten Filialnetz gab es kein Zeitfenster, in dem der Betrieb hätte stillstehen können; ein Schutzkonzept sollte verhindern, dass ein Standort während der Umstellung ausfiel. Das ist ein Einzelfall, kein Beleg dafür, dass Ausfälle immer vermeidbar sind. Technisch braucht es geprüfte Pakete und Konfigurationen (siehe die Frage zu Qualitätsprüfungen vor der Verteilung), geklärte Kompatibilität der Fachapplikationen und eine bewusste Planung von Installationszeitpunkten und Neustarts. In Microsoft Intune lassen sich zum Beispiel das Neustartverhalten je App sowie Benachrichtigungen, Verfügbarkeit und Installationsfristen je Zuweisung festlegen; andere Werkzeuge haben eigene Mechanismen. Organisatorisch hilft eine ringbasierte Verteilung: Microsoft beschreibt für Windows-Updates eine Abfolge von Preview, Limited (Pilot und Validierung auf repräsentativen Geräten) und Broad und schlägt vor, missionskritische Geräte in einen eigenen Ring zu nehmen oder bis nach der breiten Verteilung zurückzuhalten. Dazu kommen Freigaben pro Ring, Information der Nutzenden, ein vorbereiteter Service Desk, Ansprechpersonen an den Standorten und eine kontrollierte Übergabe in den Betrieb. In den veröffentlichten Behördenmandaten von Hosang Consulting gehörten klar definierte technische Arbeitspakete, Qualitätssicherung der Softwarebereitstellung, fachliche Abnahmen, nachvollziehbare Prüf- und Freigabeprozesse und eine kontrollierte Übergabe in den produktiven Betrieb zu den Massnahmen, die Risiken während Einführung und Rollout verringern sollten; bei einer regulierten Self-Service-Lösung wurden Support- und Betriebsprozesse mitgestaltet und ein produktiver Pilotbetrieb vorbereitet und begleitet. Legen Sie vor dem Start fest, welches Restrisiko akzeptiert wird und was geschieht, wenn ein Standort oder eine Gruppe trotzdem ausfällt: Ersatzgeräte oder Ausweichabläufe, Rückfall auf die Vorversion, soweit technisch möglich, ein Eskalationsweg und wer die Verteilung stoppen darf. Ein Rückfall ist nicht automatisch sicher und sollte, wo möglich, vorher geprüft werden.

Ein Sprachmodell (Large Language Model) ist die technische Komponente, die Sprache verarbeitet und erzeugt. Ein KI-Produkt ist die Anwendung, die ein oder mehrere Modelle mit weiteren Funktionen für Nutzende verbindet. Ein Agent verbindet ein Modell mit Ziel, Kontext, Regeln und Werkzeugen, sodass mehrere Arbeitsschritte ausgeführt werden können.

Die Unterscheidung zählt, weil sonst Ungleiches verglichen wird, wenn von «der KI» die Rede ist. Fragen zu Qualität, Kosten, Datenschutz und Abhängigkeit stellen sich je Ebene anders: beim Modell etwa Fähigkeiten und Austauschbarkeit, beim Produkt Konten, Datenhaltung und Bedingungen des Anbieters, beim Agenten die Werkzeuge, Rechte und Handlungen, die ihm erlaubt sind. Bei Agenten unterscheidet der Modellanbieter Anthropic zwischen «Workflows», in denen Modelle und Werkzeuge über vordefinierte Abläufe gesteuert werden, und «Agenten», in denen das Modell Ablauf und Werkzeugnutzung selbst steuert. Agenten tauschen laut Anthropic oft Antwortzeit und Kosten gegen bessere Aufgabenleistung; empfohlen wird, mit der einfachsten Lösung zu beginnen. Die praktische Folge: Je mehr ein System selbst handelt, desto wichtiger werden Mandat, Grenzen und menschliche Verantwortung. Ein Chatbot, der Entwürfe liefert, braucht andere Regeln als ein Agent, der E-Mails versendet oder Daten in einem System ändert.

Bei einzelnen Aufgaben vielleicht, aber eine Rolle ist mehr als die Summe ihrer Aufgaben. Wer Stellen streicht, bevor geklärt ist, wo Urteil, Ausnahmen, Kontextwissen und Verantwortung liegen, kann kurzfristig sparen und später mehr bezahlen.

Technische Ersetzbarkeit einer Aufgabe ist nicht dasselbe wie organisationale Funktionsfähigkeit. Viele Tätigkeiten enthalten einen Routineanteil, in dem KI stark ist, und einen Anteil aus Urteil in unklaren Lagen, nirgends dokumentiertem Kontextwissen, der Fähigkeit zu eskalieren und Verantwortung, die jemand tatsächlich trägt. Wie gross welcher Anteil ist, unterscheidet sich von Tätigkeit zu Tätigkeit und sollte vor einem Abbau geklärt sein. Rechnen Sie nüchtern und vollständig. Mindestens die Kosten, Erfahrung später zurückzuholen, falls sie dann überhaupt verfügbar ist, und die Folgen von Fehlern, die niemand mehr bemerkt, fehlen nach Einschätzung von Hosang Consulting oft im ersten Business Case. Ich empfehle, zusätzlich den Aufwand für Prüfung und Korrektur der KI-Ergebnisse, die Abhängigkeit vom Anbieter und den Lernweg für Nachwuchs einzurechnen. Ein mögliches Vorgehen: Analysieren Sie Aufgaben statt Stellen, prüfen Sie den Einsatz in einem begrenzten Pilot mit Messung, schneiden Sie Rollen neu zu, statt sie nur zu streichen, und entscheiden Sie bewusst, wofür frei werdende Kapazität eingesetzt wird. Personalentscheide gehören zu Führung und HR und unterliegen arbeitsrechtlichen Vorgaben.

Möglicherweise den Lernweg zu den Fachleuten von morgen. Einstiegs- und Routinearbeit ist nicht nur ein Kostenpunkt, sondern ein Lernfeld; wer sie weitgehend automatisiert, muss das Lernen anders organisieren.

An Routinearbeit lernen Menschen den Normalfall: Sie sehen viele Fälle, erkennen Muster, machen Fehler, erhalten Rückmeldung und übernehmen Schritt für Schritt mehr Verantwortung. Daraus entsteht das Urteil, das später bei Ausnahmen gebraucht wird. Fällt diese Stufe weg, zeigt sich die Folge verzögert: kurzfristig mehr Effizienz, mittelfristig weniger erfahrene Leute für schwierige Fälle. Das ist eine These von Hosang Consulting, keine gemessene Regel. Wer Lernfelder automatisiert, muss neue Lernwege bauen; welche Formen dafür in Frage kommen, behandelt die Frage, wie sich Nachwuchs entwickeln lässt, wenn Routinearbeit automatisiert wird. Dazu gehört eine oft übersehene Frage: Wer prüft künftig die KI-Ergebnisse, und wie lernt diese Person das Prüfen? Prüffragen vor der Automatisierung: Welche Rollen haben bisher an dieser Arbeit gelernt? Woran erkennen wir in zwei Jahren, ob genug Erfahrung nachwächst? Wer verantwortet den neuen Lernweg, und ist er budgetiert?

Ein einfacher Test: Würde die KI einem Mitbewerber in Ihrer Lage genau dasselbe raten? Wenn ja, ist es eher der Durchschnitt als ein Rat für Ihr Unternehmen. Überzeugend klingt sie, weil gute Formulierung und gute Begründung nicht dasselbe sind.

In einer im März 2026 in der Harvard Business Review veröffentlichten Untersuchung von Romasanta, Thomas und Levina empfahlen mehrere führende Sprachmodelle bei strategischen Grundsatzfragen überwiegend dieselben, gerade populären Strategien; auch veränderter Kontext änderte daran wenig. Die Forschenden nennen das «Trendslop». Die Wiedergabe beschränkt sich auf die veröffentlichte Kernaussage; Methodendetails und Zahlen der Studie sind hier nicht dargestellt. Warum solche Antworten überzeugen: Eine naheliegende, aber nicht abschliessend belegte Erklärung ist, dass Sprachmodelle Antworten erzeugen, die zu Mustern in ihren Trainingsdaten passen, und sie eloquent formulieren. Das ist riskanter, als es klingt: Ein schwacher Vorschlag, der schwach klingt, richtet wenig Schaden an. Ein schwacher Vorschlag, der brillant formuliert ist, gelangt leichter ungeprüft ins Protokoll. Erkennungsmerkmale, die ich empfehle: Die Empfehlung nennt keine eigenen Zahlen, Rahmenbedingungen oder Zielkonflikte Ihres Unternehmens. Sie wäre für jede Branche gültig. Sie nennt keine Bedingungen, unter denen sie falsch wäre. Und sie bleibt gleich, wenn Sie die Frage anders stellen. Gegenmittel: nach drei grundverschiedenen Optionen fragen, ausdrücklich die stärksten Argumente für die unpopuläre Option verlangen und die Empfehlung an Zielen, Fähigkeiten und realen Rahmenbedingungen prüfen. Eine generische Antwort kann ein Ausgangspunkt sein; zur Entscheidung wird sie erst, wenn Menschen sie am eigenen Kontext prüfen und verantworten.

Das lässt sich nur pro Anwendungsfall beantworten: Beschreiben Sie, welche Aufgabe sich wie verändern soll, messen Sie den heutigen Zustand und vergleichen Sie ihn in einem begrenzten Pilot mit dem neuen, einschliesslich Prüfaufwand, Fehler- und Folgekosten. Eine pauschale Nutzenzahl für «KI» gibt es nicht.

Präzisieren Sie zuerst den Anwendungsfall: welcher Prozess, welche Aufgabe, wer nutzt das Ergebnis und was soll besser werden, etwa Zeit, Qualität, Durchlaufzeit, Fehlerquote oder Verfügbarkeit. Messen Sie den Ausgangswert, sonst lässt sich später kein Unterschied zeigen. Fehlen Daten, benennen Sie das als Teil der Ausgangslage. Prüfen Sie den Einsatz dann in einem Pilot mit festgelegten Kriterien und Zeitraum. Rechnen Sie die Kosten vollständig: Lizenzen und Betrieb, Integration, Aufbereitung von Wissen und Daten, Schulung, Zeit für Prüfung und Korrektur der Ergebnisse, Risiken durch Fehler, Datenschutz- und Sicherheitsabklärungen sowie die Abhängigkeit vom Anbieter und die Kosten eines späteren Ausstiegs. Folgekosten wie das spätere Zurückholen verlorener Erfahrung stehen nach Einschätzung von Hosang Consulting selten im ersten Business Case; ich empfehle, auch den Lernweg für Nachwuchs mitzudenken. Unterscheiden Sie Output und Outcome: Ein eingeführtes Werkzeug ist ein Output; ob es genutzt wird und etwas verbessert, ist der Outcome. Prüfen Sie nach der Einführung mit Früh- und Spätindikatoren, ob der erwartete Nutzen eintritt, und legen Sie vorher fest, was geschieht, wenn er ausbleibt, etwa Anpassung oder Stopp.

Die technische Umsetzung ja, die Führung der Veränderung nicht. Digitalisierung und KI verändern Informationsflüsse, Rollen und Entscheidungswege; das muss die Geschäftsleitung oder eine Projektführung mit Entscheidungskompetenz steuern, gemeinsam mit IT und Fachbereichen.

Technologie wirkt oft als Verstärker der bestehenden Entscheidungskultur. Sind Rollen unklar, werden sie durch ein neues System nicht klarer; mit KI werden Unklarheiten nicht kleiner, sondern schneller wirksam. Nach der veröffentlichten Erfahrung von Hosang Consulting scheitern Digitalisierungsprojekte selten an der Technik und häufiger an Entscheidungen, die vor und während des Projekts nicht getroffen werden. Nicht delegierbar sind insbesondere: Ziel und Priorität des Vorhabens; die Entscheidung, ob es weiterläuft oder gestoppt wird; die Klärung, ob Anforderungen verstanden oder nur dokumentiert sind; welche Entscheidungen ein KI-System vorbereiten soll und wer sie übernimmt; und die Regeln für Verantwortung und Freigaben. Eine Projektführung verbindet strategische Ziele mit der operativen Umsetzung, klärt Rollen, etabliert Entscheidungswege und schafft eine Governance, die im Alltag trägt; sie lässt auch Widerspruch ausdrücklich zu. Die IT bleibt zentral für Architektur, Sicherheit, Integration und Betrieb, sollte aber nicht allein über fachliche Ziele entscheiden müssen.

Das lässt sich erst sinnvoll beantworten, wenn klar ist, welches Problem gelöst, welche Entscheidung verbessert oder welche Fähigkeit aufgebaut werden soll. Dann vergleichen Sie Optionen nach Anforderungen, Integration, Kosten über die Nutzungsdauer, Sicherheit, Datenschutz, Betrieb und Ausstiegsmöglichkeit, nicht nach Bekanntheit.

Ob Sie jetzt wählen oder zuerst klären sollten, behandelt eine eigene Frage. Diese Antwort setzt voraus, dass das Problem verstanden und die Verantwortlichkeiten geklärt sind; sonst zeigt auch das beste Werkzeug nur schneller und teurer, was vorher schon nicht funktioniert hat. Oft lohnt es sich zuerst zu prüfen, was bestehende Systeme bereits können. Auswahlkriterien: fachliche und technische Anforderungen, Integration in bestehende Systeme, Gesamtkosten über die Nutzungsdauer einschliesslich Ausstieg, Sicherheit, Datenschutz und Datenstandort, langfristiger Betrieb und Support sowie die Abhängigkeit von einem einzelnen Anbieter. Eine Schweizer Herkunft oder ein Schweizer Rechenzentrum allein garantiert noch keine digitale Souveränität. Bei KI-Lösungen kommen Fragen hinzu: Was geschieht mit eingegebenen Daten, lassen sich Modelle wechseln, und wer prüft die Ergebnisse? Vorgehen, das ich empfehle: Muss- und Kann-Kriterien vor den Anbietergesprächen festhalten, wenige Optionen mit realen Anwendungsfällen testen und den Entscheid mit Begründung, verworfenen Varianten und Ausstiegsbedingungen dokumentieren. Hosang Consulting arbeitet nach eigener Darstellung technologieoffen; welche Lösung passt, ergibt sich aus der Aufgabe, nicht aus einer Produktvorliebe.

Für ein KMU heisst digitale Souveränität, die Kontrolle über das eigene Wissen, die eigenen Entscheide und den nächsten operativen Schritt zu behalten. Dafür muss es Technologie nicht selbst entwickeln; eine Eigenentwicklung lohnt sich nur, wenn sie eine wichtige Fähigkeit besser sichert als eine austauschbare Standardlösung, und sie schafft ihrerseits Abhängigkeiten.

Hosang Consulting versteht Souveränität so: Die Menschen im Unternehmen verstehen Ziele, Zusammenhänge und Folgen und können im Ernstfall eingreifen. Das Wissen bleibt im Unternehmen, die Prozesse bleiben nachvollziehbar, und Modelle oder Werkzeuge lassen sich dort einsetzen, wo sie den grössten Nutzen bringen. Das ist keine Frage eigener Rechenzentren; auch eine Schweizer Herkunft oder ein Schweizer Rechenzentrum allein garantiert noch keine Souveränität. Zur Eigenentwicklung: Kein KMU kann jede Technologie selbst entwickeln, und es muss es auch nicht. Eine Eigenentwicklung verlagert die Abhängigkeit oft auf wenige Personen oder einen Entwicklungspartner und verlangt dauerhaft Pflege, Sicherheit und Betrieb. Wichtiger sind meist diese Fragen: Wo liegen Ihre Daten, und erhalten Sie sie in brauchbarem Format zurück? Ist Ihre Prozesslogik ausserhalb eines Werkzeugs beschrieben? Sind Entscheidungen und ihre Gründe nachvollziehbar abgelegt? Lässt sich ein Modell oder Anbieter wechseln? Praktische Schritte: Inventarisieren Sie kritische Abhängigkeiten, also Daten, Schnittstellen, Prozesslogik, Zugriffsrechte und Betriebsverantwortung. Halten Sie bei Beschaffungen Ausstiegsbedingungen fest. Und bauen Sie die Wissens- und Entscheidungsschicht so auf, dass sie einen Werkzeug- oder Modellwechsel übersteht.

Nicht zwingend. Abhängigkeit beginnt weniger bei der Wahl des Sprachmodells als dort, wo Wissen, Prozesse und Entscheide fest mit einem einzigen Anbieter verwachsen; wer diese Schicht unabhängig hält, kann Modelle wechseln. Eine Umstellung kann trotzdem aus Datenschutz-, Vertrags- oder Risikogründen angezeigt sein.

Vieles spricht nach Einschätzung von Hosang Consulting dafür, dass Modelle mit der Zeit austauschbarer werden. Der bleibende Wert liegt dann in Ihrer Wissensbasis, Ihrer Prozesslogik und Ihrer Fähigkeit zu entscheiden, auch darüber, welches Werkzeug Sie wo einsetzen. Deshalb lohnt es sich, die Wissens- und Prozessschicht unabhängig vom Modell aufzubauen. Ganz unbegründet ist die Sorge nicht: Der Zugang zu KI-Diensten kann behördlich eingeschränkt werden. So ordnete die italienische Datenschutzbehörde im März 2023 eine vorläufige Einschränkung der Datenbearbeitung durch ChatGPT für Personen in Italien an; im April 2023 wurde die Aussetzung der Massnahme an Auflagen geknüpft. Wer alles auf eine Karte setzt, wird abhängig von Entscheiden, die weit weg getroffen werden. Entscheidungskriterien: Welche Daten fliessen in das Modell, wo werden sie bearbeitet, und welche Anforderungen gelten aus Datenschutz, Branchenregeln und Kundenverträgen? Gibt es einen Plan B, etwa ein zweites Modell und exportierbare Wissensbasis, Vorlagen und Konfiguration? Ist die Integration so gebaut, dass ein Modellwechsel ohne Neubau möglich ist? Die Herkunft eines Modells allein beantwortet diese Fragen nicht.

Vor allem frühe Weichenstellungen: wo Daten gehalten werden, welche Schnittstellen entstehen, wo die Prozesslogik liegt, welche Zugriffsrechte Anbieter erhalten, wie Wissen gespeichert wird und wer im Betrieb verantwortlich ist. Problematisch wird es, wenn diese Entscheide später niemand mehr nachvollziehen oder korrigieren kann.

In Projekten wirken diese Fragen oft wie technische Details. Tatsächlich bestimmen sie spätere Spielräume. Die grössere Abhängigkeit entsteht nach Einschätzung von Hosang Consulting dort, wo Unternehmenswissen, Entscheidungslogik und operative Ausführung in einer einzigen Plattform zusammenlaufen. Halten Sie deshalb fest, welche Alternativen geprüft, welche Risiken akzeptiert, was bewusst ausgeschlossen und unter welchen Bedingungen ein Ausstieg vorgesehen ist. Wer das nicht dokumentiert, verliert mit der Zeit die Fähigkeit, eigene Entscheide zu korrigieren. Prüffragen pro Entscheid, die ich empfehle: Können wir die Daten in einem nutzbaren Format exportieren? Ist die Prozesslogik ausserhalb der Plattform beschrieben? Wer kann Schnittstellen ändern? Welche Rechte hat der Anbieter auf Daten und Systeme? Wer übernimmt im Betrieb Verantwortung, und mit welchem Wissen? Was würde ein Wechsel heute ungefähr kosten?

Behandeln Sie den Ausstieg schon in Projekt und Beschaffung als eigenen Entscheid: unter welchen Bedingungen ein Wechsel vorgesehen ist, wie Sie Ihre Daten zurückerhalten, wer sie bereinigt und was der Ausstieg über die Nutzungsdauer kostet. So wird ein späterer Systemtausch nicht zum Kontrollverlust.

Halten Sie im Projekt fest, welche Alternativen geprüft, welche Risiken akzeptiert und was bewusst ausgeschlossen wurde und unter welchen Bedingungen ein Ausstieg vorgesehen ist. Diese Punkte bleiben sonst implizit und sind später nicht mehr nachvollziehbar. In die Anforderungen einer Softwarebeschaffung gehören Punkte, die in allgemeinen Vorlagen oft fehlen: welche Daten übernommen werden und wer sie bereinigt, die Kosten über die Nutzungsdauer einschliesslich Ausstieg, Datenhaltung und Zugriff sowie die Frage, wie Sie Ihre Daten zurückerhalten, wenn Sie den Anbieter wechseln. Ich empfehle, zusätzlich Format und Frist der Datenrückgabe, die Dokumentation von Konfiguration und Prozesslogik und die Unterstützung beim Übergang zu regeln. Prüfen Sie vor der breiten Einführung, soweit möglich, einen Probeexport: Sind die Daten ausserhalb des Systems vollständig und verständlich? Ziel ist, Daten, Regeln und Verantwortungen so zu gestalten, dass ein Systemtausch nicht einem Kontrollverlust gleichkommt.

Für einfache Fragen kann das reichen; sobald ein System Entscheide vorbereiten oder selbst handeln soll, meist nicht. Dann braucht es eine strukturierte Wissens- und Entscheidungsschicht, die zeigt, was aktuell, bestätigt, widersprüchlich oder veraltet ist und wer dafür verantwortlich ist.

Ein System findet in Dokumenten nur Ausschnitte: Ein Protokoll enthält vielleicht den Entscheid, aber nicht den Grund. Eine Prozessbeschreibung zeigt den Sollablauf, nicht die im Alltag akzeptierten Ausnahmen. Eine Kennzahl zeigt eine Abweichung, nicht, ob sie schon erklärt ist. Menschen verbinden das durch Erfahrung, ein Agent sieht zunächst nur die einzelnen Stücke. Hosang Consulting beschreibt die Elemente einer solchen Schicht so: Ziele, die Prozesse, die zu diesen Zielen führen, Rollen und Verantwortungen, Entscheide mit Begründung, Kennzahlen, der Status von Informationen, also aktuell, bestätigt oder vorläufig, und Zugriffsrechte für Menschen und Agenten. Entscheidend ist nicht nur, wo Wissen liegt, sondern wie Quellen verbunden, bewertet, versioniert und verantwortet werden. Für den Aufbau empfehle ich ein schrittweises Vorgehen: mit einem begrenzten Anwendungsfall beginnen, die dafür nötigen Quellen bestimmen und bereinigen, etwa Duplikate und veraltete Fassungen, Verantwortliche je Wissensbereich festlegen, Entscheide mit Begründung erfassen, Zugriffsrechte klären und die Schicht unabhängig vom Modell aufbauen, damit sie einen Werkzeugwechsel übersteht. Der Aufwand hängt vor allem von Menge und Zustand der Quellen, der Datenqualität, den Rechten und der Pflegeverantwortung ab.

Ein wesentlicher Grund ist nach Einschätzung von Hosang Consulting fehlender oder widersprüchlicher Kontext: Viel Projektwissen liegt nicht in der Ablage, sondern in Köpfen und nie protokollierten Gesprächen. KI verarbeitet dieselben Lücken dann nur schneller; prüfen Sie deshalb die Wissensgrundlage, bevor Sie Werkzeug oder Modell wechseln.

Eine KI kann einen Entscheid lesen, ohne zu verstehen, weshalb er getroffen wurde, oder einen aktuellen Stand finden, ohne zu wissen, welche Variante bewusst verworfen wurde. Sind Informationen verteilt, widersprüchlich oder veraltet, entstehen keine besseren Einschätzungen, sondern schneller vorbereitete Unsicherheiten. Diagnosefragen: Gibt es eine gültige Fassung der relevanten Informationen oder mehrere widersprüchliche? Sind Entscheidungsgründe, Annahmen, Risiken und verworfene Varianten festgehalten? Weiss das System, welche Informationen verbindlich und welche vorläufig sind? Ist die Aufgabe präzise gestellt? Unterscheiden Sie dabei, ob ein Ergebnis falsch ist, also Fakten nicht stimmen, unpassend, also Kontext fehlt, oder nur generisch, also eine Durchschnittsantwort. Nicht jede Schwäche liegt am Kontext; auch Aufgabenstellung, Werkzeug und fehlende Prüfung spielen mit. Abhilfe: Projektwissen nachvollziehbar führen, mit Entscheidungsgründen, Annahmen, Risiken und verworfenen Varianten; klar regeln, wer Annahmen bestätigt und Informationen aktualisiert; und bei Übergaben in Betrieb oder Folgeprojekte nicht nur Dokumente, sondern auch Gründe, Abhängigkeiten und akzeptierte Risiken übergeben.

Meist nicht als erste Massnahme. Zentral gespeichert ist nicht dasselbe wie verlässlich: Auch eine neue Ablage kann voller Duplikate, veralteter Dokumente und unklarer Zuständigkeiten sein, wenn niemand Wissen bestätigt, aktualisiert und verantwortet.

Was oft eigentlich fehlt, ist ein Organisationsgedächtnis: die Fähigkeit, Wissen, Entscheide und deren Begründung so zu halten, dass sie unabhängig von einzelnen Personen zugänglich bleiben. Das ist zuerst eine Frage von Regeln und Verantwortung, erst danach von Software. Prüfen Sie vor einem Systemwechsel: Wer bestätigt Annahmen, aktualisiert Risiken und dokumentiert Änderungen? Welche Informationen sind für Folgeentscheide verbindlich? Wie werden Fassungen versioniert und veraltete gekennzeichnet? Wo bleibt die Begründung eines Entscheids? Wie werden Übergaben bei Personalwechseln und am Ende externer Mandate gemacht? Ein neues System kann sinnvoll sein, wenn das bestehende diese Regeln technisch nicht abbilden kann. Dann gehören die Regeln in die Anforderungen, und die Migration sollte Bestände bereinigen, statt sie unverändert zu übertragen. Es geht nicht darum, alles zu speichern, sondern Erfahrungswissen anschlussfähig zu halten.

Weil ein System technisch eingeführt sein kann, ohne organisatorisch angekommen zu sein. Einführung ist Bereitstellung; ob sich etwas verbessert, zeigt sich erst, wenn Rollen, Abläufe und Entscheidungswege zur neuen Arbeitsweise passen und diese im Alltag auch unter Belastung trägt.

Technologie wirkt oft als Verstärker der bestehenden Entscheidungskultur: Sind Rollen unklar, werden sie durch ein neues System nicht klarer; ist Verantwortung diffus, digitalisiert die Software die Diffusion. Hosang Consulting beschreibt als typische Lücke, dass eine neue Software eingeführt, Rollen, Prozesse und Verantwortlichkeiten aber nicht angepasst wurden. Diagnosefragen: Wird das System tatsächlich genutzt, von wem und wofür? Laufen alte Wege wie Tabellen oder E-Mail parallel weiter? Wurden Abläufe und Zuständigkeiten angepasst oder nur abgebildet? Wissen die Nutzenden, wozu das System dient, und wurden sie befähigt? War vor der Einführung festgelegt, was sich verbessern soll, und gibt es einen Ausgangswert? Wer ist nach dem Projekt für die Wirkung zuständig? Mögliche nächste Schritte: das Ziel und die erwartete Verbesserung nachträglich präzisieren, Nutzungs- und Wirkungsindikatoren erheben, die wichtigsten Hindernisse im Alltag klären und Rollen und Prozesse anpassen, statt zuerst weitere Funktionen einzuführen. Wirkung zeigt sich nicht in implementierten Funktionen, sondern darin, was danach im Alltag besser funktioniert.

Ein technisch erfolgreicher KI-Pilot ist noch kein wirksamer Arbeitsprozess. Häufig fehlen ein klarer Anwendungsfall, verantwortliche Personen, passende Abläufe, Schulung oder überprüfbare Erfolgskriterien.

Prüfen Sie den Weg vom Piloten in die tägliche Arbeit: Welche konkrete Aufgabe soll erleichtert werden? Wer nutzt das System tatsächlich und mit welchem Ergebnis? Wer kontrolliert die Resultate und entscheidet bei Fehlern? Welche Daten, Rollen und Freigaben werden benötigt? Beobachten Sie die Nutzung im realen Ablauf, nicht nur bei Demonstrationen. Klären Sie Hindernisse mit den Mitarbeitenden und passen Sie Prozess, Zuständigkeiten und Unterstützung an. Erst eine nachvollziehbare Verbesserung im Arbeitsalltag zeigt, ob die Einführung Wirkung erzielt.