Kategorie-Archiv: IT-Governance

Bei der Jahreskonferenz des Agile Business Consortium am 4. und 5. Oktober 2017 in London traf ich auf einen Management-Ansatz, der mich schon seit vielen Jahren interessiert und fasziniert: „Beyond Budgeting“. Wer es nicht kennt – erstaunlicherweise ist das immer noch ein Insidertipp – findet auf der WebSite des internationalen Netzwerks BBRT umfassende Informationen.

Was mir allerdings auf dieser Konferenz erst bewusst wurde, ist die enge Verwandtschaft der Prinzipien von Beyond Budgeting und agilem Projektmanagement. Auf die Sprünge geholfen hat mir dabei Steve Morlidge, dessen soeben erschienenes Buch eine aktuelle und kompakte Zusammenfassung gibt.

Zunächst seine Beschreibung des typischen Budgetierungsprozesses in Unternehmen:

Schritt 1: Erstelle einen Plan
Basierend auf Annahmen über die Entwicklung der Umwelt (insbesondere Kunden, Lieferanten, Wettbewerber, Märkte) und auf internen Annahmen (insbesondere Produkte, Prozesse, Technologien, Personal, Kosten) wird die Entwicklung des nächsten Geschäftsjahres beschrieben. Dieser Prozess ist unstrittig und notwendig, das Problem liegt allerdings in der Unsicherheit der Annahmen und auch, dass die Wahl eines Jahres als Planungseinheit willkürlich ist. Die Wahl der Annahmen ist nicht trivial und von vielen Unsicherheiten und Widersprüchen gekennzeichnet. Entsprechend langwierig und zeitraubend ist dieser Prozess, wenn er den Anspruch erhebt, einmalig das gesamte kommende Geschäftsjahr vorweg zu nehmen. Morlidge beschreibt als Extremfall eine Bank, die 13 Monate brauchte, um die Jahresplanung zu erstellen.

Schritt 2: Fixiere das Budget
Der finale Plan wird nach langen Verhandlungen auf die einzelnen Organisationseinheiten und Perioden (Monate/Quartale) heruntergebrochen und schließlich auch in persönliche Zielvereinbarungen übersetzt. Das Budget beinhaltet Zielwerte für zahlreiche Ergebnisvariablen wie Umsatz und Deckungsbeitrag und für Input-Variablen wie Investitionen und Kosten. Diese Werte werden „eingefroren“ und sind Vorgabe für die gesamte Geschäftstätigkeit dieses Jahres.

3: Messe und manage die Ergebnisse
Die Ist-Werte werden regelmäßig auf einer möglichst detaillierten Ebene mit den Plan-Werten verglichen. Von den Managern wird erwartet, dass sie Abweichungen verhindern oder zumindest rasch korrigieren.  Wenn Manager das nicht schaffen, wird das als Mangel an Einsatz oder Qualifikation gedeutet und entsprechend sanktioniert. Wir kennen aber auch alle die Tricks, mit denen knapp vor Monats- oder Quartals- oder gar Jahresende die Ist-Zahlen den Soll-Werten angeglichen werden. 

Steve Morlidge nennt vier Probleme des traditionellen Budgetierungsprozesses:

1. Bürokratie: Der Prozess der Erstellung eines detaillierten Budgets ist sehr zeitaufwendig und teuer.
2. Inflexibilität: Da die Budgetwerte fix sind, ist es schwierig und extrem langwierig, auf geänderte Umstände während des Geschäftsjahres zu reagieren.
3. Suboptimierung: Gute Ziele sollten ein gewisses Maß an Risiko beinhalten, also ambitioniert sein. Budgetzahlen sind aber fixe Vorgaben, so dass Risiko so weit wie möglich vermieden wird. Man bleibt also hinter den Möglichkeiten zurück; Analysten mögen übrigens auch nicht, wenn Budgetziele übertroffen werden, das wird als Zeichen mangelnder Planungskompetenz gedeutet.
4. Politisch: Besonders störend ist die Tendenz, die variablen Einkommensbestandteile möglichst vieler Mitarbeiter des Unternehmens an die Erreichung der Budgetziele zu knüpfen; daraus resultiert zwangsläufig, dass alle versuchen, die Ergebniserwartungen möglichst niedrig zu halten, um sich dann nicht für mangelnde Zielerreichung rechtfertigen zu müssen. Man versucht also, seine Messlatte möglichst niedrig zu halten, anstatt möglichst hoch zu springen.

Solange die Umwelt der großen Unternehmen relativ stabil war, konnte der Budgetierungsprozess und der Umgang mit den Budgets in der Geschäftsabwicklung immer weiter perfektioniert werden. In einer Phase hoher Volatilität der Absatzmärkte (z.B. Eintritt völlig neuer Wettbewerber in die angestammten Märkte), der Technologien und auch der Arbeitsmärkte (z.B. demografische Entwicklung) wird der traditionelle Budgetierungsprozess allerdings zur Gefahr für den Unternehmenserfolg.

Was ist die Alternative, was bedeutet „Beyond Budgeting“ in der Praxis?

Schritt 1: Messe das Ergebnis in einer sinnvollen Weise
Man muss herausfinden, welche finanziellen und nicht-finanziellen Parameter entscheidend für den nachhaltigen Erfolg des Unternehmens sind; das sind sowohl unternehmensinterne als auch externe Faktoren. Diese werden regelmäßig gemessen, die Periodizität hängt von den Gegebenheiten ab, unter denen das Unternehmen agiert und muss auch nicht für alle gleich sein. Es gibt Branchen, in denen einzelne Parameter täglich analysiert werden müssen, aber vielfach können die Perioden deutlich länger sein. Das kann sich mit der Zeit ändern, je nachdem, wie sich die Umstände verändern. Zielwerte werden nicht aus den Werten der Vorjahre abgeleitet, sondern idealerweise aus Benchmarks oder zumindest internen Vergleichen zwischen verschiedenen Organisationseinheiten. Wichtig ist, dass die Messung der Ist-Werte am Anfang und im Zentrum der Managementaktivitäten steht, nicht die Erstellung von Plänen. In Wien gibt es dafür den saloppen Spruch, hier übersetzt in deutsche Schriftsprache: „Was es wiegt, das hat es“.

Schritt 2: Prognostiziere wo notwendig
Beyond Budgeting spricht lieber von „Forecasts“ als von Plänen. Damit soll deutlich gemacht werden, dass alle Aussagen über die Zukunft unsicher sind, mehr oder minder fundierte Annahmen. Anstatt zu versuchen, die Zukunft immer genauer vorherzusagen, was in immer mehr Unternehmen und Branchen nicht gelingen kann, soll man daran arbeiten, die Reaktionszeiten zu verkürzen und flexibler zu werden.

Schritt 3: Plane und steuere den Ressourceneinsatz kontinuierlich
Beyond Budgeting ordnet die Ressourcen nur lose den geplanten Aktivitäten zu. Auf unerwartete Herausforderungen wird mit einer Änderung des Ressourceneinsatzes reagiert, das gilt insbesondere auch für finanzielle Mittel. In welcher Frequenz solche Änderungen stattfinden, ist nicht allgemeingültig fixiert, es hängt von den konkreten Umständen ab.  

Schritt 4: Beteilige alle an gemeinsamen Erfolgen
Individuelle Leistungsvorgaben und damit verbundene Incentives werden als kontraproduktiv gesehen, umso mehr, wenn sie von Budgetwerten abhängen, die mit den anfangs geschilderten Unzulänglichkeiten behaftet sind. Überdies hängt der Erfolg eines Unternehmens nie von der Leistung einzelner ab, sondern ist ein Resultat des Zusammenwirkens aller. Daher sind variable Einkommensbestandteile im Modell von Beyond Budgeting das Ergebnis einer Verteilung des finanziellen Erfolgs des Unternehmens auf die Mitarbeiter nach einem definierten Schlüssel. Der Erfolg wird nicht als Differenz zum Plan definiert, sondern wird absolut gemessen, wie ja auch die Eigentümer am tatsächlichen Gewinn beteiligt werden und nicht am Delta zu einem im Voraus willkürlich festgelegten Wert. 

Soweit eine kurze Darstellung des Management-Modells von Beyond Budgeting, angelehnt an das Buch von Steve Morlidge. Dort gibt es noch mehr zu diesem Thema, vor allem zu den Konsequenzen dieses Management-Paradigmas für die Führung und Organisation von Unternehmen. Das ist ein Fokusthema des deutschen Pioniers von Beyond Budgeting, Niels Pfläging.

Hier möchte ich aber den Bezug zur Entwicklung des Projektmanagements herstellen. Die Planung von Projekten nach dem Wasserfallmodell ähnelt doch frappierend dem Budgetierungsprozess und erfolgreiches Projektmanagement ist dort auch dadurch gekennzeichnet, dass die Pläne eingehalten werden.

Interessant, dass die Standish Group, Herausgeber des jährlichen Chaos-Reports über die Erfolgsquote von IT-Projekten, ihre Kriterien für den Projekterfolg vor einigen Jahren geändert hat. Kriterium des Erfolgs ist der am Ende erzielte Nutzen für den Kunden, auch wenn die Projektergebnisse sich deutlich vom ursprünglichen Plan unterscheiden. Es kann ja sein, dass sich die Rahmenbedingungen des Projektes geändert haben, der Scope aus guten Gründen erweitert oder reduziert wurde oder aufgrund von Problemen mit Lieferanten, Technologien oder Ressourcen Änderungen des Planes notwendig und für das Ergebnis sogar positiv waren.

Agiles Projektmanagement stellt auch die Messung der Ergebnisse in den Vordergrund aller Überlegungen. Zentrale Steuerungsinstanz ist das Burn-Down-Chart, in möglichst kurzen Abständen wird der tatsächliche Fortschritt, gemessen an der Akzeptanz realer Software durch die realen Anwender ermittelt und dann reagiert. Der Forecast wird regelmäßig angepasst und die wirksamste Methode, um Abweichungen von den gewünschten Ergebnissen zu korrigieren ist die Steuerung des Personaleinsatzes. Pläne sind Annahmen als Grundlage der Projektsteuerung, sie sind aber nicht in Stein gemeißelt, sondern Orientierungsrahmen, die solange gelten, wie sie funktionieren.

Ich denke, dass mit der unaufhaltsamen Verbreitung von agilen Projektmanagement-Methoden auch der zu Unrecht vernachlässigte Ansatz von „Beyond Budgeting“ sich stärker durchsetzen wird. Das Ergebnis wird in den Unternehmen, die beides implementieren, ein Leistungsschub sein und nicht zuletzt wird sich auch die Lebensqualität für Manager und Mitarbeiter deutlich verbessern.

Ursprung

Seit knapp 20 Jahren ist mit der Agilität auch der Workshop Facilitator als Rolle im agilen Umfeld entstanden.

Im systemischen Kontext existiert auch seit langer Zeit die Konstellationen eines „Splitting Team“. Ein 2er-Team mit der Teilung auf die Aufgabe und den Ablauf.

Im englischen Sprachgebrauch werden Betreuer bzw. Leiter von Abläufen als Facilitator bezeichnet. So auch beispielsweise beim Lego Serious Play.

Prozessbegleiter sind im Beratungsbereich auch immer wieder zu finden. Diese Übersetzung ist bei größeren Umfängen sehr passend. Der Workshop-Facilitator hat somit schon ein längeres Dasein.

Anerkennung

International ist der Heimathafen die IAF (International Association Facilitation). Diese bietet weltweit Kongresse, Mitgliedschaften, Informationen und auch Akkreditierungen.

APMG hat zusammen mit den Strategic Facilitators aus UK 2013 das Framework Facilitation™ kreiert. Ebenso wie in anderen Bereichen werden Akkreditierungen für Foundation und Practitioner angeboten.

Rollen

Der Projektmanager nutzt von jeher Meetings – also Workshops – für die Umsetzung seiner mannigfachen Aufgaben wie Anforderungserhebung, Abstimmungen oder Planungen u.v.m.

Motivation

Je komplexer die Aufgabe, je vielfältiger die Stakeholder und/oder direkt im Workshop Beteiligten, je emotionaler die Stimmung oder je drängender die Zeit, desto mehr ist der Projektmanager von der Erfüllung seiner Aufgaben überfordert. Oft schon, wenn dies nur als einzelne „Erscheinung“ auftritt und erst recht in Kombinationen

Einfache Moderationsmethoden sind durchaus bei geringeren Anforderungen beste Werkzeuge. Meist haben diese aber ihre Grenzen, da diese weder typbezogen noch gar in einem Ablaufkontext kombiniert eingesetzt werden können. So werden wir bspw. auch nicht mit unserer Heckenschere den Rasen mähen – sprich gleiche Werkzeuge für unterschiedliche Aufgaben einsetzen.

Manchmal werden dann Entscheidungen getroffen, deren Halbwertszeit nur sehr kurz bemessen ist und Torpedierungen zu erwarten sind. Manchmal werden gar keine Entscheidungen getroffen oder Personen ausgegrenzt. Auf jeden Fall dient dies der Qualität und sonstigen Auflagen des Projekts nur in geringem Maße. Wenn wir dazu auch noch die vorliegenden Forschungsergebnisse oder die Phänomene vom „Groupthink“ beachten, brauchen wir uns über viele Konsequenzen nicht mehr wundern.

Betroffene Rollen sind auch der Lenkungsausschuss bei geforderten Entscheidungen oder der Teammanager beim Umsetzen von Arbeitspaketen.

Umsetzung

Der Workshop-Facilitator ist eine zusätzliche Rolle. Meistens beheimatet im PMO – intern oder extern – hat der die Auflagen der absolut glaubwürdigen Unabhängigkeit bezüglich des Ergebnisses und der flexiblen Prozesskompetenz.

In kleineren Projekten oder bei Aufgaben mit geringeren Herausforderungen kann es durchaus Sinn machen, wenn sich der Projektmanager die eine oder andere Zusatzkompetenz für einfache Entscheidungsfindungen und Personenkenntnisse zulegt. Ansonsten sollte dieses Feld den dafür ausgebildeten Spezialisten überlassen werden. Deren sich der Projektmanager bedienen sollte.

Facilitation wirkt von außen gesehen teilweise als Magie. Damit diese entstehen kann, ist eine intensive Auseinandersetzung mit der Materie notwendig. Dienlich dabei ist ein systemisches Fundament.

Ergebnis

Die Aufgabe des Workshop-Facilitators ist es, stabilere Ziele in höherer Qualität herbei zu führen. Ziele, hinter denen die Beteiligten auch weiterhin stehen. Dazu ist keine Fachkenntnis erforderlich, sondern ausschließlich das Verstehen der Absichten. Wenn das gezeigte Führungsmodell Iceberg™ zum Einsatz gelangt, wird der Facilitator zusammen mit dem Aufgabenverantwortlichen und den Beteiligten pro Ebene eine Vereinbarung der Unterstützungsart treffen. So weiss jeder, was vom anderen erwartet wird und aus welchem Grunde welche Aktivitäten initiiert werden.

Begleiterscheinungen

Neue Wege bedingen oft eine radikale Abkehr alter Muster. Je neuer und abstrakter solche Vorhaben sind, desto mehr fehlt die Sicherheit. Als solche bezeichnen wir, wenn wir wissen, woran wir sind (was, wo, wie, wozu und warum). Menschen mit größerem Abstand zu neuen Bereichen oder auch größerer Angst vor Abkehr von alten Pfaden werden als eher „dysfunktional“ empfunden. Dem folgen die Klassifizierungen „transitional“ und „prozess-achtsam“. Bei ersteren erfolgen keine Fragen und das Feedback gibt der Facilitator laut für die Gruppe von sich. Bei der transitionalen Gruppe gibt es schon einzelne Aktivisten wohin gegen die prozess-achtsame Gruppe von sich aus zu Feedback greift. Das Verständnis wächst so von Status zu Status.

Fazit

Workshop-Facilitation ist eine absolute Schlüsselfertigkeit. Der Einsatzbereich ist mannigfach und weit über das Projekt-, Programm- oder Portfoliomanagement hinaus. Viable Projects GmbH ist die einzige Accredited Training Organization in DACH für diesen Bereich. Die Trainings erfolgen im kleinsten Rahmen, um jedem Teilnehmer einen maximalen Effekt an Entwicklung zu ermöglichen. Viable Projects GmbH bietet auch Entwicklungsbegleitung in der Praxis sowie die Übernahme von Dienstleistungen als Facilitator an.

Wie oft habe ich schon gehört, man müsse dem dauernden „Wünsch dir was“ der Anwender endlich Einhalt gebieten. Sie sollen sagen was sie wollen und nicht dauernd neue Anforderungen einwerfen, so werden wir ja nie fertig. Zweifellos kann man nicht in Produktion gehen, bevor die Anwendung eine hinreichende Stabilität erreicht hat, das gilt sowohl für die Features aus fachlicher Sicht als auch für die technische Umsetzung. Daher gibt es die „Freeze“-Phasen, zuerst Anforderungs-Freeze, dann Code-Freeze. Zum Schluss werden nur noch schwere Fehler korrigiert. Wer kann dagegen sein, es so zu machen? Natürlich niemand! Hat jemand schon erlebt, dass der ausgerufene Freeze tatsächlich eingehalten wurde? Im Prinzip schon, wenn man ein paar Ausnahmen als Bestätigung der Regel akzeptiert.

Ich habe selbst schon auf diesem Weg Projekte zum Abschluss gebracht, allerdings habe ich dabei auch eine Erfahrung gemacht, die vom Common Sense etwas abweicht. Ich meine nämlich, dass es vom Reifegrad der Anwendung abhängt, ob neue Anforderungen auftauchen oder nicht. Ab einem gewissen Zeitpunkt gehen die Change Requests wie von selbst dramatisch zurück, wenn man nämlich die Anforderungen hinreichend verstanden und umgesetzt hat. Vorher kann man alles versuchen, es ist vergeblich. Es liegt also meist nicht an der Begehrlichkeit der Anwender, wenn man nicht zu einem Ende kommt, sondern an objektiven Mängeln dessen, was man bisher im Projekt geschaffen hat.

Mein erstes größeres IT-Projekt übernahm ich als Krisenmanager, weil es einfach nicht  gelingen wollte, eine Abnahme zu erzielen. Immer tauchten neue Punkte auf, die noch fehlten oder nicht passten. Ein Pflichtenheft gab es zwar, nur hatte sich die Anwendung schon so weit von den dort niedergeschriebenen Vorgaben entfernt, dass eine Berufung darauf nach hinten los gegangen wäre: ich war nämlich Mitglied der Geschäftsleitung der Firma, die das System zu entwickeln hatte und man hätte uns mit Recht vorwerfen können, das Pflichtenheft nicht beachtet bzw. es nicht aktualisiert zu haben. Das wäre nochmals Mehraufwand gewesen, den uns natürlich niemand bezahlt hätte. Was also tun? Ich erfand das Konstrukt der „vorläufigen Abnahme“ mit folgendem Briefing an die Anwender auf Kundenseite: „Wir wissen, dass Sie das System noch nicht abnehmen werden, weil noch Punkte fehlen oder nicht passen. Aber wir schauen uns jetzt alles gemeinsam an und halten fest, was sie daran hindert, eine Abnahme durchzuführen.“ Und das funktionierte tatsächlich. Wir bekamen so ein Pflichtenheft mit einer endlichen Liste von noch zu erledigenden Anpassungen und Erweiterungen, die mussten wir abarbeiten und dann klappte es tatsächlich mit der Abnahme. Budgetär war das Projekt natürlich kein Erfolg für uns, aber dafür war ich nicht verantwortlich, ich hatte die Never-Ending-Story zu einem Abschluss gebracht, das war ein Erfolg, mehr war nicht mehr drin.

Ein anderes Mal kam ich als externer Projektleiter auf Zeit in ein Projekt, das durch beachtliche Termin- und Budgetüberschreitungen in die Krise geraten war. Der bisherige Projektleiter hatte das Handtuch geworfen. Ziel des Projektes war die Entwicklung und der Rollout einer umfangreichen Softwarelösung für einen wichtigen Unternehmensbereich. Die Entwicklung der Software lag in den Händen eines Tochterunternehmens, das wiederum den größten Teil des Auftragsvolumens an einen externen Subunternehmer vergeben hatte, der daher für den Erfolg des Projekts bestimmend war.

Aufgrund der aufgetretenen Verzögerungen und Budgetüberschreitungen waren alle Beteiligten unter Druck. Die Versuchung, diesem Druck durch Schuldzuweisungen zu entkommen, war groß, das Klima im Programm und im Projekt entsprechend belastet. Eine intensive und konflikthafte Auseinandersetzung mit Change Requests war das dominierende Thema der Projektarbeit, als ich meinen Job antrat. Die Erwartung an mich war, endlich das Entstehen von Change-Requests zu stoppen, vor allem dadurch, dass ich das „Wünsch Dir was“ der Anwender unter Kontrolle bekomme.

Was war aber das wirkliche Hindernis für einen Konsens über die noch offenen Anforderungen zwischen Anwendern und der IT? In einer Reihe von Vier-Augen-Gesprächen zeigte sich, dass die „Lieferanten“ die mangelnde Disziplin der Anwender bei der Kontrolle des Scopes und die daraus resultierenden Change-Requests als zentrales Problem klassifizierten, die „Anwender“ hingegen sahen die mangelnde Eignung des bisher gelieferten Systems für den praktischen Einsatz als KO-Kriterium.

Die Frage nach einem Pflichtenheft oder einer anderen Art von Anforderungsdefinition ergab, dass es zwar ein Pflichtenheft gab, dieses jedoch aus Sicht der Anwender gravierend unvollständig war. Aus diesem Grund war es auch nie abgenommen worden, galt also offiziell als vorläufig und sollte in der Projektarbeit konkretisiert werden.

Der Engpass waren also die gegensätzlichen Situationsbeschreibungen von „Lieferanten“ und „Kunden“. Während die Software-Entwickler davon ausgingen, dass die Anforderungen klar seien und nur noch Change Requests gegenüber dieser Anforderungsdefinition zulässig seien, versuchten die Anwender mit Hilfe  von Change Requests die nicht vorhandene Anforderungsdefinition zu ersetzen. Was für die einen Changes (also Zusatzanforderungen) waren, war für die anderen unverzichtbarer Teil des Projektscope. Man hielt die Teile in der Hand, es fehlte aber eine Gesamtsicht.

Als Maßnahme zur Krisenbewältigung wurde daher eine (neuerliche) Phase der Anforderungsanalyse eingeschoben. Diese war zwar schwer durchzusetzen, weil ja offiziell alles klar war, aber unverzichtbar für den Erfolg, wie sich später bestätigte. Die Analyse wurde in einer kleinen Gruppe im Dialog abgewickelt, die Kommunikationswege wurden verkürzt, die Ergebnisse in Textform für alle verständlich dargestellt (es war letztlich das, was man ein Fachkonzept nennt). Auf der Seite der Lieferanten wurde eine Zwischenebene eingespart. Diese war vor allem mit der Identifikation von Change Requests und deren Bepreisung beschäftigt gewesen und hatte peinlich darauf geachtet, dass kein direkter Kontakt zwischen Anwendern und Entwicklern stattfand. Das Klima der Zusammenarbeit verbesserte sich signifikant und nachhaltig, aus dem Gegeneinander wurde durch den direkten Kontakt immer mehr ein Miteinander. Am Ende konnte der GoLive in einem akzeptablen Termin- und Budgetrahmen geschafft werden.

Ohne einen Schritt des bewussten Zurückweichens hinter verhärtete Argumentationslinien wäre in beiden Fällen ein Abschluss noch lange nicht gelungen.

English Version here/Englische Version hier.

Immer wieder und in verschiedenen Kontexten wird W. Ross Ashby’s „Gesetz der erforderlichen Vielfalt“ zitiert und ich habe noch nie einen Widerspruch vernommen. Ich habe Ashby’s Buch „Einführung in die Kybernetik“ schon vor langer Zeit gelesen und viel daraus gelernt. Das so viel zitierte Gesetz (Kapitel 11/6) hat mich natürlich damals sehr beeindruckt und überzeugt. Aber bald hatte ich mit den daraus gezogenen Schlussfolgerungen meine Probleme und diese wurden immer größer.

Warum ist das wichtig und vor allem, was hat das mit unseren konkreten Herausforderungen beim Management von Projekten zu tun? Ich meine, dass die Schlussfolgerungen ausgesprochen irreführend sind und dass damit der Erfolg von Projekten gefährdet wird. Es ist also nicht nur mein ganz persönliches Verständnisproblem, es geht um gravierende praktische Konsequenzen.

Beginnen wir an der Quelle. Ashby bezieht sich auf die Spieltheorie und er beschreibt die Situation zweier Spieler R und D. Wenn D einen Spielzug macht, muss R entscheiden, mit welchem Spielzug er entgegnet. Die Anzahl der möglichen Spielausgänge hängt nun davon ab, wie groß die Anzahl möglicher Spielzüge von D ist und wie weit es R gelingt, diese Vielfalt zu reduzieren, so dass idealerweise nur die Ergebnisse eintreten, in denen er der Sieger ist. Wenn immer nur ein Ausgang möglich ist, egal was D tut, wo wäre die Vielfalt der Ergebnisse auf ihr absolutes Minimum reduziert, nämlich auf 1. Wenn R zwei verschiedene Spielzüge zur Verfügung hat, so kann er die Vielfalt der Ergebnisse bestenfalls auf die Hälfte der Möglichkeiten reduzieren. Das Gesetz lautet: „Wenn also die Vielfalt in den Ergebnissen auf eine festgelegte Zahl oder auf einen festgelegten Bruchteil von D’s Vielfalt verringert werden soll, dann muss R’s Vielfalt zumindest auf das notwendige Minimum ansteigen. Nur Vielfalt in R’s Zügen kann die Vielfalt der Ergebnisse senken“. Und einige Absätze weiter der Satz, den alle zitieren: „Nur Vielfalt kann Vielfalt zerstören“.

Dass der letzte Satz so nicht zutreffen kann, sollte eigentlich sofort auffallen. Nehmen wir eine Fliege als Beispiel, die einen komplizierten Kurs fliegt. Es genügt ein gezielter Schlag mit der Fliegenklappe (eine Aktion mit sehr geringer Komplexität), um die Bewegungsvielfalt der Fliege ein für allemal zu zerstören. Das Beispiel werden manche als hanebüchen klassifizieren, aber es bringt uns auf den entscheidenden Punkt. Wollten wir die Vielfalt der Positionen der Fliege relativ zu uns reduzieren, so müssten wir genau so beweglich sein wie die Fliege und ihr auf dem Fuß folgen. Wenn man also im gleichen Regelwerk agiert wie das Gegenüber (um von der unglücklichen Fliege zu abstrahieren), dann gilt Ashby’s Gesetz. Wenn aber ein Spieler das Paradigma wechselt, verliert es seine Gültigkeit.

Das Gesetz der erforderlichen Vielfalt gilt, wenn alle innerhalb des gleichen Ziel- und Regelsystems agieren. Auch das Ziel des Spieles ist wichtig. Nehmen wir ein reales Spiel wie Tennis oder Fußball. Im Tennis gibt es immer einen Sieger und einen Verlierer, im Fußball kann es auch ein Remis geben. Akzeptiert man die Maximierung der Anzahl an Siegen und die Minimierung der Anzahl an Niederlagen als Ziel, so ist die Vielfalt der Ergebnisse drastisch reduziert. Erfolge im Fußball sind sowohl mit einem komplexen Kurzpassspiel möglich (Tiki-Taka, wir erinnern uns an die Erfolge des FC Barcelona) wie auch mit einer Defensivstrategie (Catenaccio, damit war Inter Mailand einst sehr erfolgreich). Tiki-Taka wird man wohl eher mit dem Attribut „Vielfalt“ assozieren, nur kann man diese Vielfalt mit einer deutlich weniger vielfältigen Spielweise „zerstören“, wie seit einiger Zeit empirisch zu beobachten ist.

Nun aber genug der Analogien, wenden wir uns unserem Handlungsfeld zu. Würde man Ashby’s Gesetz so interpretieren, wie es alle mir bekannten Business-Autoren tun, dann müsste ein komplexes, durch Vielfalt an möglichen Ergebnissen gekennzeichnetes Projekt durch eine entsprechend komplexe Projektorganisation bewältigt werden. Bleiben wir kurz in der Terminologie von Ashby: Ein komplexes Projekt ist durch eine Vielfalt an Einflussfaktoren und Ergebnissen (einschließlich aller relevanten Zwischenergebnisse) gekennzeichnet. Dem begegnet man durch eine komplexe Projektorganisation (Matrix ist da immer eine gute Idee), eine Vielzahl an genau definierten Arbeitspaketen, detaillierte Terminpläne mit Meilensteinen, Abhängigkeitsmatrizen, Risikokatalogen, Controllingreports etc. etc. Erkennt man Abweichungen vom Plan, so wird darauf mit noch komplexeren Strukturen und Prozessen reagiert, denn: Nur mit Komplexität kann man Komplexität beherrschen (wenn wir das irreführende Wort zerstören ersetzen).

Aber: Damit tappen wir doch genau in die Falle, die Paul Watzlawick in seiner „Anleitung zum Unglücklichsein“ so treffend beschrieben hat: „Mehr desselben“. Er sieht darin „eines der erfolgreichsten und wirkungsvollsten Katastrophenrezepte, das sich auf unserem Planeten im Laufe der Jahrmillionen herausgebildet und zum Aussterben ganzer Gattungen geführt hat (S. 28)“.

Ich habe es schon so oft erlebt: Werden die Termine nicht gehalten, wird die Terminplanung verfeinert und das Controlling ausgebaut. Einmal musste ich, als Krisenmanager kurzfristig eingesprungen, zweimal pro Woche die Einhaltung von ca. 50 Detailterminen reporten, zum Arbeiten blieb entsprechend weniger Zeit. Erst nach einigen Wochen gelang es mir, das auf einmal pro Woche zu reduzieren und nach einigen Zwischenerfolgen konnten wir auf zweiwöchige Iterationen umstellen, über deren Ergebnis berichtet wurde. So kamen wir auch zum Erfolg. Wir haben also auf die Vielfalt der Projektherausforderungen (viele Termine hielten nicht oder konnten nicht garantiert werden) mit einer Reduktion der Komplexität reagiert. Luhmann hat ausführlich dargelegt, dass genau die Reduktion von Komplexität die entscheidende kulturelle Leistung darstellt. Angesichts des erdrückenden Umfangs seiner Publikationen möchte ich hier auf ein Schlüsselwerk verweisen, wo er Vertrauen als Mechanismus der Reduktion sozialer Komplexität darstellt. Für unseren Kontext gilt z.B., dass Vertrauen in die Kompetenz des Projektteams eine deutliche Reduktion der Kontrollmechanismen erlaubt und umgekehrt.

Betrachten wir agile Vorgehensmodelle, so fällt auf, dass diese deutlich weniger komplex organisiert sind als klassisch geführte Projekte. Die fixe Taktung von Iterationen, das Herunterbrechen der gesamten Arbeitslast auf eine Backlog-Liste von User-Stories, der Verzicht auf Erfolgskontrollen durch Bekanntgabe von Fertigstellungsgraden (anstatt dessen dient die Auslieferung von funktionierender Software am Ende jeder Iteration als einzig relevantes Fortschrittsmaß) sind Beispiele für radikale Vereinfachungen. Dabei sind aber gerade agile Vorgehensmodelle geschaffen worden, um Projekte abzuwickeln, die sich durch hohe Komplexität (Moving Target) auszeichnen. Der Erfolg gibt ihnen recht. Die Erfolgsrate großer Softwareprojekte ist bei Anwendung agiler Methoden deutlich höher als bei „klassischen“ Vorgehensmodellen, umso mehr, je größer (und damit wohl auch komplexer) das Projekt. Das ist der klare Befund der Standish Group. Hier dazu die Grafik (leider schwer lesbar), mehr und besser lesbar dazu hier:

Zusammengefasst: Auf Komplexität der Aufgabenstellung kann man mit erhöhter Komplexität der Projektorganisation reagieren. Das ist allerdings keine gute Idee. Besser ist es, dieser Komplexität mit einfachen, aber wirkungsvollen Strukturen zu begegnen. Das kann Scrum als besonders unkomplexe, weil streng vordefinierte Abwicklungsmethode sein. Es kann XP sein, mit einer besonders einfachen Intervention: Lasse Anwender und Techniker direkt zusammenarbeiten. Es kann auch Lean, Kanban oder DSDM sein. Dazu habe ich in einem anderen Blogpost eine Übersicht mit Linkliste gegeben.

Ist Ashby’s Gesetz also falsch? Nein! Mit Ashby’s Gesetz verhält es sich genau so wie mit den Gesetzen der Physik. Das Fallgesetz etwa besagt, dass eine Feder und eine Bleikugel gleich schnell zu Boden fallen. Im Alltag können wir dieses Phänomen nicht beobachten, denn das Gesetz gilt so nur im absoluten Vakuum. Ashby’s Gesetz gilt nur innerhalb eines geschlossenen Regelsystems mit fixen Zielgrößen. Das wird bei den gängigen Schlussfolgerungen, die für die Praxis gezogen werden, übersehen. Das wiederum führt zu negativen Konsequenzen. Keep it simple ist auch eine zu undifferenzierte Empfehlung; es kommt darauf an, eine geeignete Vereinfachung zu finden. Agile Vorgehensmodelle sind dafür ein Beispiel.

Alle stark sachorientierten Leute (und dazu zählen wohl alle, die im IT-Umfeld arbeiten), haben eine Allergie gegen Befindlichkeiten: Emotionen führen dazu, dass ein sinnvoller Vorschlag nicht akzeptiert und umgesetzt wird. Man möge Befindlichkeiten hintanstellen, Emotionen ausblenden etc., das sind die Appelle, die man immer wieder hört. Menschen reagieren auf solche Aufrufe allerdings oft mit umso mehr Ablehnung, empfinden das als Versuch der Manipulation. Spricht man den Umstand der störenden emotionalen Reaktionen ausdrücklich an, wird es oft noch schlimmer, das wird als Unterstellung diffamiert und die Gesprächsatmosphäre ist nachhaltig verdorben. Metakommunikation ist nicht immer eine gute Lösung.

Was kann man also tun? Teambuilding ist eine wirkungsvolle Maßnahme, kostet allerdings viel Zeit und die Frage ist auch, welche Personen als Angehörige des Teams gelten und welche nicht. In den Großprojekten, mit denen ich vorwiegend zu tun habe, ist eine solche Maßnahme schwer finanzierbar und wahrscheinlich würde die Diskussion über die Abgrenzung des Teilnehmerkreises mehr zerstören als durch das Training einer ausgewählten Gruppe gewonnen wird. Gesucht sind also Ideen, die ohne großen Aufwand und möglichst unauffällig in der laufenden Projektarbeit integriert werden können.

Ein hervorragendes Beispiel dafür, wie solche Maßnahmen aussehen können, ist für mich das Buch von Manfred Prior, der „Minimax-Interventionen – 15 minimale Interventionen mit maximaler Wirkung“ beschreibt.

Prior schreibt für Psychotherapeuten, seine Beispiele sind daher für Projektmanager etwas exotisch und das ist wohl auch der Grund, warum dieser Ansatz wenig bekannt ist. Aber die Ideen sind, mit entsprechend anderen Formulierungen, in jedem Kontext sinnvoll und hilfreich. Man sollte auch über die Zeichnungen und die mundartlichen Texte eines Bären (auch dieser von geringem Verstand) hinweg lesen, ich jedenfalls habe diese als störend empfunden, ohne dass dadurch der Wert des Buches in Mitleidenschaft gezogen würde.

Einige Interventionen, die meiner Meinung nach in Projekten unmittelbar umsetzbar und nützlich sind, möchte ich hier herausgreifen und mit eigenen Beispielen erläutern:

Intervention 1: „In der Vergangenheit …“
Wenn ein Problem angesprochen wird, dann mit dem kleinen Zusatz „bisher …“ oder „In der Vergangenheit…“.
Also nicht: „Die Testabdeckung ist unzureichend“, sondern „Die Testabdeckung ist bisher unzureichend“.
Nicht: „Die unzureichende Mitarbeit der Fachabteilung kennen wir als Problem ja zur Genüge’“, sondern „In der Vergangenheit hatten wir regelmäßig Probleme, eine ausreichende Mitarbeit der Fachabteilung zu erreichen“.
Gleiche Aussage, ganz unterschiedliche Wirkung! Und wenn jemand sagt, das ist doch unehrlich? Stimmt nicht, denn wer weiß, wie die Zukunft sein wird, alle Aussagen können sich daher nur auf die Vergangenheit beziehen. Hier wird es nur ausgesprochen. Wenn man etwas ändern will, ist es ja auch sinnvoll, die Chance der Veränderung schon in der Formulierung zu betonen. Das ist also nicht unehrlich, sondern vernünftig und erfolgsorientiert.

Intervention 2: Nicht „ob“, sondern „wie“, „was“ und „welche“
Wir kennen die Aussage, etwas sei keine Frage des Ob, sondern nur des Wie. So direkt ausgesprochen, kann das Widerstand hervorrufen. Wenn man das aber in ganz normale Formulierungen integriert, ist die positive Wirkung eher möglich und wahrscheinlich.
Also nicht: „Es ist unklar, ob wir die Freigabe des Auftraggebers zur Aufstockung der Ressourcen bekommen“, sondern „Es ist unklar, wie wir die Freigabe … bekommen können“.
Nicht: „Es ist offen, ob wir dafür zeitgerecht eine Lösung finden“, sondern „Es ist offen, welche Lösung wir dafür innerhalb des gegebenen Zeitrahmens finden können“.
Ob es funktioniert ist in beiden Varianten offen gelassen, aber die Aufforderung, nach Lösungen zu suchen ist deutlich stärker ausgeprägt, wenn man den Empfehlungen Priors folgt.

Intervention 7: „Noch nicht …“
Verwandt mit Intervention 1, aber noch stärker zukunftsorientiert und eine positive Veränderung nahe legend.
Also nicht: „Wir haben keinen abgestimmten Plan für das Vorgehen in der nächsten Projektphase“, sondern „Wir haben noch keinen abgestimmten Plan für ….“.
Nicht: „Uns fehlt die verbindliche Zusage, dass Frau Maier in den nächsten zwei Monaten Fulltime dem Projekt zur Verfügung steht“, sondern „Uns fehlt noch die verbindliche Zusage …“.
Wieder, rein auf der Sachebene die gleiche Aussage, auf der Beziehungsebene eine völlig andere Wirkung. Der Handlungsappell ist unterschwellig, aber wirksam in die Aussage verpackt.

Intervention 10: „Angenommen, Sie würden …“
Ratschläge sind selten willkommen, vor allem, wenn sie ungebeten erteilt werden; aber selbst dann gibt es emotionale Hürden, weil man sich in seinem Entscheidungsspielraum eingeengt fühlt.
Daher nicht: „Sie sollten den Termin um einen Monat zu verschieben“, sondern „Angenommen, Sie würden den Termin um einen Monat verschieben?“.
Nicht: „Es bietet sich doch an, den Auftrag an die Firma Hypertalk zu erteilen“, sondern „Angenommen, Sie würden den Auftrag der Firma Hypertalk erteilen?“.

Intervention 12: „Nicht-Vorschläge“
Verwandt mit Intervention 10 ist eine Variante der paradoxen Intervention. Gute Ideen, die sehr leicht auf Widerstand in Form eines „Ja, aber …“ treffen, kann man durch die Paradoxie des Voranstellens einer Verneinung leichter annehmbar machen. Es geht dabei nicht um ein Täuschungsmanöver, man darf auch nicht frustriert sein, wenn diese Verneinung vom Gesprächspartner angenommen wird. Man muss also die Möglichkeit des Gegenübers, den Rat abzulehnen, sowohl äußerlich als auch innerlich, sowohl sachlich als auch emotional, akzeptieren.
Man leitet also Sätze ein mit Formulierungen wie: „Und es ist nicht nötig, dass …“; „Es muss jetzt noch nicht so sein, dass …“; „Es ist derzeit nicht unbedingt notwendig, dass Sie …“ usw.
Also nicht: „Sie müssen das Projekt jetzt auf Rot setzen“, sondern „Es ist nicht nötig, das Projekt auf Rot zu setzen, aber die Situation ist doch kritisch“.
Nicht: „Wir sollten den Meilensteinplan anpassen“, sondern „Es ist nicht unbedingt notwendig, den Meilensteinplan schon jetzt anzupassen, aber wir müssen im nächsten Lenkungsausschuss über unsere Einschätzung der Lage berichten“.
Ich denke, das Prinzip ist durch die Beispiele hinreichend klar: Man signalisiert aktiv, dass unser Gegenüber nicht in eine bestimmte Richtung gedrängt wird, sondern wir signalisieren durch die Formulierung deutlich, dass es seine bzw. ihre Entscheidung ist. Würden wir das allerdings so aussprechen („Es ist natürlich Ihre Entscheidung, allerdings scheint mir, dass ….“), ist die Wirkung eine fundamental andere.

Priors Buch ist sehr stark auf Psychotherapie zugeschnitten. Aber bei entsprechender Bereitschaft, die Ideen in den eigenen Berufskontext zu übersetzen, lohnt sich die Lektüre (und ein Preis von nicht einmal 10 € fällt auch in die Minimax-Kategorie).

P.S.: Wer mehr über paradoxe Interventionen wissen möchte, ist mit diesem Buch von Christian Ankowitsch hervorragend bedient. Leicht lesbar, amüsant und doch seriös.

Die Professionalisierung des Projektmanagements brachte es mit sich, dass es die Profession des Projektmanagers gibt. Große Unternehmen haben einen Pool an Projektmanagern (oft in einem PMO zusammengefasst), die in unterschiedlichen Projekten zum Einsatz kommen. Meist wird das verbunden mit einer Standardisierung, im DACH-Raum ist das sehr oft IPMA, international dominiert PMI, in einigen Regionen ist es PRINCE2. Es ist klar, dass solche Standards nicht auf die Spezifika bestimmter Branchen oder Projekttypen eingehen können, sie haben den Anspruch, für alle Arten von Projekten zu gelten. Solange es um die Vereinheitlichung von Begriffen, um Checklisten für die Vollständigkeit von Projektplänen, Beispiele für Best Practices  etc. geht, ist das eine sinnvolle und wertvolle Aktivität. Allerdings besteht die Gefahr, dass man diese Normierung für ausreichend hält, um sich als Projektmanager zu qualifizieren. Ich sehe in diesen Standards etwas, das in der Medizin mit den Kenntnissen der Anatomie und der medizinischen Fachterminologie zu vergleichen ist. In der Medizin ist wohl jedem klar, dass die perfekte Kenntnis des Pschyrembel nicht reicht, um ein guter Arzt zu sein.

Allrounder sind keine gute Wahl

Immer wieder hatte ich die Gelegenheit, mit Universal-Projektmanagern zusammenzuarbeiten. Die Erfahrungen waren unterschiedlich, je nachdem, in welchem Gesamtkontext das war. Es gibt in größeren Projekten genügend Arbeit für Projektmanagement im Sinne von Projektadministration und je qualifizierter diese Projektmanager sind, umso besser. Das funktioniert gut, wenn eine am konkreten Inhalt des Projektes orientierte Expertise im Projekt ausreichend vorhanden und diese mit einer ausreichend starken Position im Projekt vertreten ist.

Das führt wieder zum Grund meiner Vorbehalte gegen den kompetenzorientierten Standard der IPMA, wenn nämlich die Erwartung genährt wird, ein Projektmanager sei tendenziell erfolgreicher, wenn er in allen relevanten Kompetenzbereichen stark ist. Selbst wenn man so einen Wunderwuzzi zur Verfügung hat, ist das kein Vorteil: Es verführt dazu, zu wenig in eine leistungsfähige Teamstruktur zu investieren. Wenn dieses Universalgenie dann einmal ausfällt oder das Projekt einfach zu groß ist, um von einer dominanten Person gemanagt zu werden, ist die Krise umso stärker. Richtig ist, dass in einem Projekt alle erforderlichen Skills vorhanden sein müssen, um es zum Erfolg zu führen. Wie sich diese Skills aber auf die beteiligten Personen verteilen, ist je nach Situation gestaltbar. Insofern ist auch die Regel, man möge Organisationen nicht rund um Personen gestalten, zu relativieren. In einem Projekt mit gegebenem Terminrahmen muss man sich nach der Decke strecken und kann nicht darauf warten, die idealen Personen zu einer idealen Projektorganisation zu finden.

Alles ist möglich, nichts ist fix? So schlimm ist es auch wieder nicht. Es gibt meiner Meinung nach zwei geeignete Ansätze, mit diesen Herausforderungen umzugehen.

Projektmanagement ist Teamwork und braucht keine Universalgenies

Der eine führt über die Definition der Prozesse, die in einem Projekt zu exekutieren sind. Diesen Weg geht PMI mit insgesamt 47 Prozessen, die Projektmanagement ausmachen. PRINCE2 nennt 7 Prozesse, die in zwei oder mehr Phasen jeweils zu exekutieren sind. Die ISO 21500 folgt auch dem Prozessansatz und beschreibt 39 Prozesse, die weitgehend denen von PMI entsprechen. Die Unterschiede zwischen diesen Ansätzen bestehen letztlich in einer unterschiedlichen Granularität der Prozessbetrachtung, ansonsten sind die Unterschiede nicht so gravierend, dass man einen Glaubenskrieg führen könnte. Zu den Skills, die Projektmanager haben können bietet übrigens PMI auch einen Leitfaden an, der diese Kompetenzanforderungen sinnvollerweise aus den Prozessen ableitet: welche Skills braucht man, um die jeweiligen Geschäftsprozesse erfolgreich zu exekutieren. Durch wieviele Rollen und Personen man diese Skills abdeckt, bleibt dem spezifischen Projekt überlassen, was auch nur so sinnvoll ist.

Der zweite  Ansatz, der speziell auf das Management von IT-Projekten zielt, kommt vom Agile Business Consortium, das den Schwerpunkt auf ein Rollenmodell legt. Wie in Rollenmodellen üblich, muss nicht jede Rolle von einer Person besetzt sein, es kann eine Person mehrere Rollen abdecken oder eine Rolle mit mehreren Personen besetzt sein.

Das Set an Rollen muss passen

Die Rollen des Auftraggebers („Business Sponsor“) und des Projektmanagers müssen wir hier nicht gesondert beschreiben, diese sind allgemein bekannt und üblich. Interessant ist allerdings, dass es auf oberster Ebene die Rollen „Business Visionary“, „Technical Coordinator“ und „Business Analyst“ gibt. Damit wird die enorme Bedeutung des Projektinhaltes für den Projekterfolg deutlich gemacht und adäquat in der Projektorganisation abgebildet.

Business Visionary ist meist eine Person, die im Projekt stärker eingebunden ist als der Auftraggeber und dafür verantwortlich ist, die inhaltliche Ausrichtung des Projektes in allen Phasen zu steuern. Es handelt sich dabei um Vorgaben und Entscheidungen, die den Nutzenbeitrag des Projektes für den Auftraggeber sicherstellen.

Ich kenne eine dem Business Visionary entsprechende Rolle in den anderen Projektmanagement-Standards nicht; natürlich ist der Product Owner im Scrum in Teilen damit vergleichbar, aber die visionäre und  innovative Ausrichtung bleibt dort doch der Interpretation der Rolle durch den jeweiligen Product Owner überlassen. Kritisch merke ich an, dass im Scrum der Product Owner vor allem der Entlastung des Teams dient, er liefert Input, er priorisiert und das Team (eine im Scrum sehr technisch ausgerichtete Gruppe) muss sich um diese bei jedem Entwickler zutiefst unbeliebten Themen nicht kümmern. Im Scrum ist ja generell das Business eher out of scope, nur der Product Owner vertritt diese Stakeholder.

Der Technical Coordinator erfüllt aus technischer Sicht die gleiche Funktion wie der Business Visionary aus unternehmerischem Blickwinkel. Er sichert die Übereinstimmung der Projektergebnisse mit der IT-Unternehmensarchitektur bzw. stimmt die Projektentscheidungen mit übergeordneten technischen Vorgaben und Rahmenbedingungen ab. Bleibt also im Scrum und auch im Extreme Programming (XP) die Frage der Architektur immer im Dunkeln, wird diese in diesem Rollenmodell auf höchster Ebene verankert.

Im Rahmen des Solution Development Teams gibt es zusätzlich noch die Support-Funktionen Business Advisor bzw. des Technical Advisor, die das operative Pendant und erste Ansprechpartner des Business Visionary bzw. des Technical Coordinator sind. Im Team selbst nehmen eine oder mehrere Personen die Rolle des Business Ambassador ein, um die Details zu allen Fragen der Geschäftsanforderungen zu klären; damit wird eine der Stärken des XP übernommen, allerdings in einen deutlich stärker strukturierten Ansatz integriert.

Last, but not least muss die Rolle „Business Analyst“ hervorgehoben werden. Dieser ist das Bindeglied zwischen der Auftraggeberseite (wird hier „Projektebene“ genannt) und dem „Solution Development Team“ (das ist die Umsetzungsinstanz, die üblicherweise als Projektteam bezeichnet wird). Das Rollenprofil „Business Analyst“ integriert Aspekte des Product Owners im Scrum mit der traditionellen Rolle des Requirement Engineers. Entscheidend ist allerdings das damit verbundene Rollenverständnis; hier unterscheidet sich das Modell des Agile Business Consortiums von anderen Ansätzen deutlich. Der Business-Analyst agiert als Bindeglied zwischen Business und IT, allerdings nicht als Empfänger und Überbringer von Informationen und auch nicht als Übersetzer, sondern als „Facilitator„, der dafür sorgt, dass die Kommunikation zwischen den beteiligten Personen funktioniert und immer an den übergeordneten Zielen des Projektes ausgerichtet bleibt.

Insgesamt hat für mich das Modell des Agile Business Consortiums den großen Vorteil, dass die Stärken des „traditionellen“ Projektmanagements und die der agilen Vorgehensmodelle in einer idealen Weise integriert werden. Man kann große Projekte nicht mit selbstgesteuerten Teams abwickeln und man kann Innovation nicht in einer Kommandostruktur realisieren. Und man muss für jedes Projekt die bestmögliche Verteilung von Rollen auf die verfügbaren Personen finden und im Verlauf eines Projektes auch immer wieder anpassen. That’s life!

Noch eine Anmerkung: Alle Rollen stehen Männern und Frauen offen, angesichts der vielen Rollen, die hier genannt werden, habe ich aus Platzgründen auf die Geschlechtsneutralität der Bezeichnungen verzichtet.

Mein Blutdruck ist stabil und im Idealbereich. Aber wenn ich diesen Satz höre, dann steigt er blitzartig an. Zuständigkeit ist ein Begriff aus der Verwaltung, dort verliert er allerdings seit vielen Jahren stetig an Bedeutung. Man muss nicht mehr vom Schalter 1 zum Schalter 5 wechseln und dann wieder zurück zu Schalter 1, wenn man z.B. einen Reisepass braucht, es wird an einer Stelle erledigt. „One Face to the Customer“ gilt zu Recht als Maxime des Kundenkontaktes. Wenn ich also in einem Projekt diesen Satz höre, dann herrscht hier offenbar ein Denken, das wir alle überwunden haben sollten.

Natürlich gilt: Man muss auch Nein sagen können und man soll sich nicht für alles verantwortlich fühlen. Das ist richtig und als Selbstschutz auch notwendig. Aber wenn Rollendefinitionen in Projekthandbüchern und Projektaufträgen vor allem dazu verwendet werden, um klar zu stellen, wofür man nicht verantwortlich ist, dann läuft etwas grundlegend schief.

Was ist die Alternative? Ich selbst verwende das Wort Zuständigkeit überhaupt nicht, ich spreche immer von Verantwortung. Der Unterschied ist manchmal gering, meist aber entscheidend.

Was heißt „Verantwortung“?

Zunächst die Frage, was versteht man unter „Verantwortung“? Ich sehe das als die Verpflichtung, dafür zu sorgen, dass Zusagen eingehalten werden. Wenn das einmal nicht gelingt, dann ist man also daran schuld? Ja, so könnte man es ausdrücken. Wenn man sich aber als dafür verantwortlich sieht, ist das auch „nur“ ein anderes Wort, es macht aber einen großen Unterschied. Darüber, wie die Wortwahl das Ergebnis einer Kommunikation beeinflusst, habe ich an anderer Stelle schon mehr geschrieben, daher gehe ich hier nicht näher darauf ein.

Verantwortung übernehmen heißt, für die Durchführung vereinbarter Arbeiten in der festgelegten Weise zu sorgen und notwendige Entscheidungen in verbindlicher und umsetzbarer Form herbeizuführen. Ob man eine Aufgabe selbst erledigt oder diese delegiert bzw. einem anderen Teammitglied überträgt oder einen Dienstleister damit beauftragt, hängt von der Situation ab, ändert aber nichts an der persönlichen Verantwortung.

Typische Rollen in Projekten und deren Verantwortung

In einem Projekt gibt es typische Rollen und mit jeder Rolle ist ein bestimmtes Paket an Verantwortung verbunden.

Projektauftraggeber tragen die Verantwortung dafür, dass der Projektauftrag klar formuliert ist, dass die Machbarkeit des Projektes gegeben ist,  die notwendigen Ressourcen für die Projektrealisierung in der vereinbarten Weise zur Verfügung stehen und auf gravierende Änderungen der Rahmenbedingungen und Ziele mit angemessenen Anpassungen des Projektauftrages reagiert wird.

Projektleiter tragen die Verantwortung dafür, dass alle notwendigen Aufträge an das Projekt und innerhalb des Projektes erteilt, verstanden und akzeptiert werden und bei Abweichungen des Projektablaufes vom Plan geeignete Korrekturmaßnahmen eingeleitet werden.

Teilprojektleiter tragen die Verantwortung dafür, dass ein klarer Auftrag für das Teilprojekt erteilt wird und die für dessen Realisierung notwendigen Aufgaben im Teilprojekt auftragsgemäß wahrgenommen werden. Gleiches gilt für Arbeitspaketverantwortliche.

Projektmitarbeiter (damit auch Projektleiter und Teilprojektleiter) tragen die Verantwortung dafür, dass die Aufgaben der Arbeitspakete bzw. Teilprojekte, an denen sie beteiligt sind, auftragsgemäß im Sinne der Ziele des Gesamtprojektes erfüllt werden. In besonderem Maße – aber nicht nur – gilt dies für jene Aufgaben, die sie persönlich übernommen haben.

Push or Pull? Das ist nicht die Frage!

Eng verzahnt mit der Übernahme von Verantwortung ist der Umgang mit Information. Hier gilt für mich folgende Regel: Information ist grundsätzlich (a) eine Holschuld für jeden, der eine Information braucht und (b) eine Bringschuld für jeden, der eine Information besitzt.

Das Prinzip der Holschuld wäre überflüssig, wenn jeder wüsste, was andere an Informationen benötigen und rechtzeitig daran denken würde, diese weiterzugeben. Da dieses Prinzip der Bringschuld selbst bei bestem Willen aller Beteiligten nie lückenlos funktioniert, ist es notwendig, einen solchen Überschuss an Informationspflichten vorzusehen.

Jedes Ergebnisdokument, jede Präsentation und jede sonstige Information ist so zu gestalten, dass der Inhalt für die Adressaten der Information verständlich ist. Es darf die „Übersetzung“ von Informationen in die eigene Problem-, Kenntnis- und Interessenslage nicht bewusst auf den Informationsempfänger übergewälzt werden (es bleibt immer noch genug an unabsichtlichen Verständnisbarrieren). Dabei sind alle Aspekte der Kommunikation zu berücksichtigen, inbesondere die Handlungsaufforderung. Diese muss explizit formuliert werden und dazu gehört auch die Benennung der dafür verantwortlichen Person. Wenn diese noch nicht festgelegt werden kann, dann die Nennung jener Person, die dafür sorgt, dass jemand gefunden wird, der die Aufgabe übernimmt.

Dazu gehört auch, dass in jedem Mail eine klare und gesondert hervorgehobene Aussage enthalten ist, welche Aktivität man von den Empfängern erwartet (Stellung nehmen, durchführen, genehmigen, weitergeben, …).  Ausführliche Informationen ohne konkrete Handlungsaufforderung an die Adressaten dienen meist nur dem Abwälzen von Verantwortung („Sie haben diese Information ja per Mail erhalten, aber nicht reagiert“).

Aber auch hier gelten Bring- und Holschuld ergänzend: Wer eine Information nicht versteht, nicht erkennen kann, was erwartet wird, hat die Pflicht, sofort nachzufragen.

Schriftlichkeit ist zwingend, wenn damit Effizienz und Verbindlichkeit des Informationsaustausches gefördert werden. Das ist öfter der Fall als man mag, denn wer schreibt schon gerne Protokolle. Trotzdem gilt: Keine Besprechung ohne Ergebnisprotokoll oder einer für alle nachvollziehbaren und akzeptierten Ergebnisdokumentation!

Der Umgang mit Terminen – Erfolgsfaktor Nr. 1

Ein weiterer Schlüsselfaktor für die erfolgreiche Wahrnehmung von Verantwortung ist der Umgang mit Terminen.  Jede Verzögerung treibt den Projektaufwand in die Höhe, in der Bauwirtschaft gilt die Gleichung: Bauzeit = Baukosten. Das Problem sind die vielen kleinen Verzögerungen, die sich zu einer großen Gesamtverzögerung hochschaukeln. Termintreue ist daher in jedem Teilbereich die oberste Maxime. Das ist die zentrale Botschaft der Critical Chain Methode (CCPM) und die Praxis zeigt, dass die strenge Termindisziplin in jedem Arbeitspaket der Schlüssel für die Termindisziplin des Gesamtprojektes ist.

Das heißt für jedes einzelne Teammitglied: Reicht die eigene Arbeitskapazität nicht aus, um eine Aufgabe termingerecht und in der geforderten Qualität zu bewältigen, so muss jedes Teammitglied, egal in welcher Rolle, rechtzeitig für Zusatzkapazitäten sorgen (dafür in Betracht zu ziehen sind in dieser Reihenfolge: gegenseitige Hilfe im Arbeitspaket bzw. im Teilprojekt, Hilfe aus anderen Teilprojekten oder extern). Dass dafür ein Instanzenweg über Projektleitung und oft sogar Projektauftraggeber notwendig ist, enthebt nicht der Pflicht, alles daran zu setzen, die notwendigen Korrekturmaßnahmen zu initiieren. „Dafür bin ich zuständig“ und „Ich habe ja gleich gesagt, dass das unrealistisch ist“ sind keine akzeptablen Argumente in einer erfolgsorientierten Projektkultur.

Es gibt sowohl „haupt“- als auch „nebenberufliche“ Projektmitarbeiter. Es ist Aufgabe jedes Teilprojektleiters, darauf zu achten, dass das Arbeitsvolumen in angemessener Weise, insbesondere in bewältigbarer Weise, verteilt wird.

Es ist wichtig, dass Projektmitarbeiter mit geringerem Zeitanteil den Bezug zum Projekt nicht verlieren. Dafür eignet sich z.B. eine Steuerung des Projekteinsatzes in intensive, begrenzte Phasen mit Unterbrechungen. Es ist Aufgabe der hauptberuflichen Projektmitarbeiter, auf die wirksame Einbindung der mit geringerem Zeitanteil am Projekt Beteiligten zu achten.

Das Prinzip Selbstverantwortung – auch hier zentral

Verantwortung gilt allerdings auch für die eigene Person. Denn: Gute Leistungen erfordern gute Leistungsfähigkeit. Wer zuviel arbeitet, gefährdet nicht nur die eigene Gesundheit und die sozialen Kontakte (Familie, Freunde), sondern auch die Qualität seiner Arbeit. Freizeit und Urlaub sind daher notwendig und unverzichtbar, müssen allerdings unter Berücksichtigung der Projekterfordernisse und Termine geplant und mit dem Projektleiter abgestimmt werden. Wenn es „brennt“ (insbesondere also wenn ein kritischer Termin gefährdet ist), muss im Projekt mit vollem Einsatz gearbeitet werden. Wer dies auch dann tut, wenn es nicht brennt, hat keine Reserven mehr für die wirklichen Notfälle.

Null-Fehler-Strategie und Fehlerkultur – oft missverstanden

Was immer man auch tut und richtig macht: Fehler kommen vor. Wie verträgt sich das mit der Null-Fehler-Philosophie, für die ich eintrete? Null-Fehler ist die Grundeinstellung, Fehler werden nicht einfach hingenommen, sondern sie werden so schnell und so wirksam wie möglich korrigiert. Am Beispiel von Softwareprojekten hier mehr zu diesem Thema.

Wenn ein Problem auftaucht, das die Aufgabenerfüllung behindert, muss jeder, der dies erkennt, sofort nach einer Lösung suchen, die die Zielerreichung sichert. Wer ein Problem erkennt, dass nicht ihn selbst, sondern einen anderen Projektmitarbeiter bei dessen Aufgabenerfüllung behindern könnte, hat ebenfalls die Pflicht, aktiv zu werden, indem er den Betroffenen zum frühestmöglichen Zeitpunkt informiert.

Verantwortung ist also keine Frage der Abgrenzung, sondern der Bündelung aller Kräfte im Dienste des Projekterfolges insgesamt. Denn: Entscheidend für die Beurteilung des Projektes ist der Gesamterfolg. Niemand kann Erfolg haben, wenn andere im Projekt erfolglos sind. Es gibt letztlich nur den gemeinsamen Erfolg, der zählt. Je größer der gemeinsame Erfolg, umso größer kann der persönliche Erfolg jedes Einzelnen sein. Wenn ich mich also abgrenze, meinen persönlichen Erfolg maximiere, ohne links und rechts zu blicken, werde ich langfristig nicht erfolgreich sein können. Das bezahle ich mit Stress und letztlich einer Einbuße an Lebensqualität. Und dafür ist jeder selbst verantwortlich (und meinetwegen auch zuständig ;-).

Autoren wie Scholz bezeichnen diese Phase auch als „Kulturignoranz“ (2).  Die Aufmerksamkeit für die Unternehmenskultur erstarkt deutlich, als vielbeachtete Autoren wie Peters und Watermann (3) sowie in der Folge Deal und Kennedy (4) damit beginnen, die Unternehmenskultur zu beschreiben. Sie zeichnen ein System von Eigenschaften und Werten, die es in ihrer Gesamtheit den Angehörigen eines Unternehmens erleichtern, ihre Arbeitsergebnisse performant zu verrichten. Wenngleich diese Betrachtung eingängig erscheint und sicher auch heute für viele Arbeitgeber den Begriff der Unternehmenskultur vollständig ausfüllt, adressiert das Konzept ausschließlich die funktionalen Eigenschaften einer Kultur.

 Im Folgejahr veröffentlichte Schein sein System der Kulturebenen (5) und zeigt auf, dass Unternehmenskultur sich in Sprache, Kleidung und Umgangsformen darstellen kann, aber durch instinktive Grundannahmen und gemeinsam geteilte Werte konstituiert wird. Mit diesem mehrdimensionalen Modell werden beschreibbare Objekte sowie kognitive Konstrukte präzise umrissen und grundlegender Bestandteil vieler fortfolgender Definitionen. Nach dieser Beschreibung zeigte Schreyögg (6) mit seiner Einführung der Kulturstärke und Kulturwirkung den Einfluss von Unternehmenskultur, den diese auf ihre Angehörigen haben kann. Er identifizierte positive Wirkungen wie Identifikations-, Motivations-, Koordinations- sowie Profilierungsfunktion auf der einen, aber auch negative Effekte wie das Denken in Stereotypen und reduzierte Lösungsidentifikation auf der anderen Seite.

 Ausgelöst durch die starken Konzentrationsbestrebungen der weltweiten Wirtschaft veröffentlichen Gallivan und Srite (7) 2005 ihre Untersuchungen über die Interdependenz von nationaler Kultur und Unternehmenskultur in der Informationstechnologie. Sie plädieren in ihrer Literaturrecherche für eine holistische Betrachtung dieser beiden Perspektiven und unternehmen damit den Versuch, die beiden unterschiedlichen Stränge des wissenschaftlichen Diskurses zu einem zu vereinen.

 Kann die Unternehmenskultur Einfluss auf ein agiles Projekt haben?

Diese Frage wird sich bereits der ein oder andere Projektleiter gestellt haben, doch lässt sie sich wissenschaftlich längst nicht so leicht beantworten, wie man annehmen würde. Denn bei einem Projekt – ob nun agil oder klassisch ausgeführt – handelt es sich um eine komplexe Struktur mit vielen Variablen. So zeigt Khan (8) mit seiner umfassenden Literaturrecherche allein 34 unterschiedliche Projekterfolgsmerkmale auf.

 2002, ein Jahr nach der Veröffentlichung des agilen Manifests, stellen Lindvall et. al. (9) fest, dass die wichtigsten Erfolgsfaktoren eines Projektes die Kommunikation, das Personal und die Kultur seien. Auch wenn diese Autoren eine Definition der begünstigenden Kultur für agile Projekte zunächst nicht geben, zeigen sie die grundlegende Kohärenz der Kultur von Unternehmen und dem Erfolg eines Projektes auf. Den Versuch, diese Lücke zu schließen, unternimmt Highsmith (10) und prägt dabei den Begriff des Ökosystems, in dem ein Projekt ausgeführt werden muss. Dieses Ökosystem konstituiere sich durch die Ansichten der Organisationsangehörigen darüber, welche Praktiken als hilfreich wahrgenommen werden und weshalb. Highsmith bietet unter Zuhilfenahme des Kulturmodells von Schneider (11) zwei Kulturen an, in denen er die Ausführung von agilen Softwareprojekten als besonders erfolgversprechend ansieht. Insbesondere die Kompetenzkultur, in der das Wissen der Individuen in den Vordergrund gestellt werde sowie die Kooperationskultur, die durch die synergetische Zusammenarbeit geprägt sei, seien für die Anwendung von agilen Softwareentwicklungsmodellen förderlich.

 Robinson und Sharp (12) verdeutlichen in einer Implementierungsbeobachtung der Softwareentwicklungsmethode „Extreme Programming“, dass sich eine erfolgreiche Kultur nicht durch die Forderung zur Einhaltung von Prinzipien – hier die des agilen Manifests – erzwingen lässt, wenngleich sie essentiell für die erfolgreiche Anwendung einer Entwicklungsmetode und damit für die Fortuna des Projektes sei. Vielmehr rekurrierten die Organisationsmitglieder bei der Bildung einer begünstigenden Umgebung auf das Vorhandensein von gegenseitigem Respekt und Verständnis. Gleichzeitig stellen die Autoren aber auch den subsidiären Charakter der Existenz der Prinzipien fest.

 Gleichwohl sich diese Beobachtung nur auf eine der differenten agilen Entwicklungsmethoden bezieht, zeigt sie die Kohärenz von begünstigender Unternehmenskultur und erfolgreicher Entwicklungsmethode. Diesen Zusammenhang nennen auch Boehm und Turner (13) sowie Ivari und Ivari (14). Letztere sekundieren mit der Feststellung, agile Softwareentwicklungsmethoden würden durch hierarchische Unternehmenskulturen nicht begünstigt werden, den Befund Highsmiths, der diese Kulturform (Control Culture) ebenfalls als nicht unterstützend angesehen hatte.

 Nerur et al. (15) nehmen Kernaussagen, die Highsmith, Robinson und Sharp erarbeitet haben, wieder auf und postulieren, dass für den Übergang vom Bisherigen zu agilen Softwareentwicklungsmethoden eine Kultur geprägt von Zusammenarbeit, Kommunikation und gegenseitiger Wertschätzung obligat sei. Weiter weisen sie aber auch darauf hin, dass ein Kulturwandel extrem komplex sein könne. So seien die traditionellen Methoden von Sicherheit, Vorhersagbarkeit und einer klaren Weisungs- und Entscheidungsstruktur geprägt. Agile Methoden hingegen erforderten die Akzeptanz des Unvorhersehbaren und kooperative Entscheidungen, welche altbewährte Unternehmenskulturen schnell an ihre Grenzen führen können. Sie plädieren daher für eine fundierte Prüfung vor dem Einschlag des agilen Weges. Diesem Weg weiter folgend untersucht Livermore (16) den Zusammenhang von Trainings, externen Informationsquellen und anderer Unterstützung bei der erfolgreichen Einführung einer agilen Softwareentwicklungsmethode. Hierbei kann er nachweisen, dass der Einsatz von unterstützenden Trainings und Zugang zu Informationsquellen die Einführung positiv unterstützen kann, wohingegen die gemeinsame Zusammenarbeit an einem Standort per se nicht als unterstützend identifiziert werden konnte.

 Chow und Cao (17) untersuchen den Zusammenhang der Kultur, in der ein Projekt ausgeführt wird, und dessen Erfolg. Neben anderen Faktoren können die Autoren dabei nicht ausdrücklich nachweisen, dass eine positive Korrelation zwischen der organisatorischen Umgebung, also unter anderem der Unternehmenskultur, und dem Projekterfolg besteht. Stankovic et al. (18) nehmen die Erfolgsfaktoren von Chow und Cao erneut auf und können diese wiederum zwar nicht signifikant nachweisen, aber ebenso wenig, dass die Unternehmenskultur maßgeblichen Einfluss auf den Projekterfolg hat. Diese kontrastierenden Beobachtungen zum Einfluss der Kultur als Umgebungsvariable können Campanelli und Parreiras (19) in ihren Arbeiten nicht bestätigen. Letztere verifizierten ausdrücklich ihre Hypothese über die Relation zwischen der Kultur und erfolgreicher agiler Softwareentwicklung und schlagen für das ihrer Ansicht nach existente Lager der Traditionalisten, durch die Empfehlung einer adaptiven Methode aus plangetriebenen und agilen Methoden eine Brücke, um situationsgerechten Projekterfolg zu erreichen. Nerur reiht sich damit ebenfalls in die Linie der Autoren ein, nach deren Auffassung Unternehmenskultur durchaus maßgeblichen Einfluss auf die erfolgreiche Ausführung der agilen Softwareentwicklung hat.

 Kann nun abschließend mit Sicherheit festgestellt werden, dass die Unternehmenskultur entscheidend für den Erfolg agiler Projekte ist?

Wahrscheinlich nicht. Zumindest konnten die bisherigen Untersuchungen keinen signifikanten Einfluss der Kultur eines Unternehmens auf den Erfolg eines agil ausgeführten Projektes nachweisen.

 Die Erfahrungen aus diversen agilen Projekten bei unseren Kunden mit unterschiedlichen Unternehmenskulturen zeigen, dass eine erfolgreiche Teambildung und ein methodisches Vorgehen noch vor der Transformation einer Unternehmenskultur als Erfolgsmerkmal hervorzuheben sind. Die Zusammenführung der richtigen Personen und die Schaffung einer produktiven Arbeitsatmosphäre kann durch Sie als Projekt-, Teilprojekt- oder Programmleiter direkter beeinflusst werden.

Wir haben den Prozess der Teambildung bereits in diversen, auch standort- und länderübergreifenden Projekten beobachten und positiv beeinflussen können. Gerne stehen wir auch Ihrem Team mit unserer Expertise zur Seite und behalten dabei den wissenschaftlichen Diskurs stets im Auge, um mit Ihnen fundierte Entscheidungen für Ihren Projekterfolg zu treffen.

 Der Autor des Artikels, Kai Alexander Hanus, ist Senior Consultant im Kompetenzcenter Business Consulting des Geschäftsbereichs Versicherungswirtschaft der FINCON Unternehmensberatung GmbH und verfügt über mehr als neun Jahre Erfahrung in IT-Projekten der Versicherungsbranche.