PMI hat mit Disciplined Agile (DA) einen integrativen Ansatz entwickelt, dessen vier Kernaussagen ich voll unterstützen kann. Die deutsche Übersetzung ist sperrig, daher zitiere ich das Original:
DA wendet sich gegen Ansätze, die sich agil nennen, in Wirklichkeit aber starre Regelwerke sind. SAFe eignet sich besonders dafür, denn man kann aus den definierten Meetings mit vorgeschriebenen Intervallen und Rollen ein bürokratisches Monster erzeugen, das AINO ist, „Agile in name only“.
DA hat einen wunderbaren Begriff kreiert, den man ebenfalls nicht gleichwertig ins Deutsche übersetzen kann: WoW (Way of Work). Jedes Projektteam muss seinen WoW finden, um die eingangs genannten Postulate zu erfüllen; die Doppeldeutigkeit von Wow ist natürlich nicht zufällig (siehe Punkt 4 oben). Tailoring, die Anpassung der Projektorganisation, der Entscheidungs- und Steuerungsprozesse, der Teamzusammensetzung etc. an den spezifischen Kontext ist die größte Herausforderung. Und es ist keine einmalige Aktion, sondern erfordert einen kontinuierlichen Verbesserungsprozess (siehe Abbildung 1).
Abbildung 1: Kontinuierlicher Verbesserungsprozess (© PMI, Choose your WoW, 2022)
Man sieht, dass DA in völliger Übereinstimmung mit der Empfehlung von Bruce Lee ist.
Wie löst DA aber die Gefahr der völligen Orientierungslosigkeit und Beliebigkeit, denn mit dem einfachen Rat: „Mache es irgendwie, nur richtig!“, ist uns auch nicht geholfen. Und wie vermeidet man, erst wieder ein überladenes System an Vorschriften zu werden?
Zunächst verabschiedet sich DA vom Anspruch, bestehende Projektmanagement-Paradigmen zu ersetzen und positioniert sich als „agnostische Sammlung guter Ideen“, wobei diese nicht auf die bekannten agilen Ansätze beschränkt sind (siehe Abbildung 2).
Abbildung 2: DA ist eine agnostische Sammlung guter Ideen (© PMI, Choose your WoW, 2022)
Beim Umgang mit diesen guten Ideen denken wir wieder an Bruce Lee.
Was sind besonders gute Ideen, die man sorgfältig auf ihre Eignung im konkreten Kontext prüfen sollte. Ich nenne einige Beispiele aus meiner persönlichen Sicht, wobei weder die Liste der Paradigmen noch die der dort angeführten guten Ideen vollständig ist:
Und wer sagt, dass man diese guten Ideen nicht kombinierten kann oder darf? Nur Dogmatiker und die tun das aus einer Position der Schwäche, sie fühlen sich durch die Wahlfreiheit überfordert.
DA bietet aber mehr an als nur eine Aufforderung, gute Ideen zu nutzen, egal woher sie kommen. Zunächst gibt es eine enorm hilfreiche Darstellung jener Faktoren, die den Kontext eines Projektes bestimmen (siehe Abbildung 3).
Abbildung 3: Faktoren, die den Kontext eines Projektes determinieren (© PMI, Choose your WoW, 2022)
Für mich ist diese Darstellung allein hinreichend, um die Absurdität jedes „One size fits all“-Ansatzes zu demonstrieren. Wofür ist z.B. Scrum ideal und ausreichend? Man verbinde die jeweils innersten Punkte mit einer Linie, dann hat man die ideale Konstellation für Scrum, in einzelnen Dimensionen kann man mit Scrum auch noch die nächste Stufe gut abdecken, aber je weiter man nach außen geht, umso weniger wird man mit Scrum das Auslangen finden, obwohl für einzelne Aufgabenbereiche trotzdem Scrum der beste Ansatz sein kann.
Ich gehe hier nicht darauf ein, wie in DA die Wahl des Vorgehensmodells gestaltet wird, das würde den Rahmen dieses Newsletters sprengen. Es ist auch meiner persönlichen Meinung nach nicht der stärkste Teil von DA, hier hat man wohl auch aus Marketing-Gründen versucht, SAFe etwas entgegen zu setzen und begibt sich damit in die Gefahr, auch die Nachteile von SAFe zu reproduzieren.
Uneingeschränkt genial finde ich allerdings den Ansatz, die Wahl des besten Vorgehens innerhalb der einzelnen Aufgabenbereiche zu unterstützen. Ich greife hier den Bereich der Anforderungsanalyse heraus (siehe Abbildung 4). Die Gesamtaufgabe wird in Teilaufgaben heruntergebrochen und zu jeder Teilaufgabe werden mögliche Umsetzungsansätze genannt. Teilweise ist es eine ungeordnete Liste an Möglichkeiten, wo besonders empfohlene Optionen durch Fettdruck hervorgehoben werden. In einigen Fällen gibt es einen empfohlenen Entwicklungspfad (durch einen Pfeil dargestellt), dort signalisiert der Fettdruck, welche Option jedenfalls angestrebt werden sollte, nicht immer ist es die am höchsten gereihte Option.
Der DA-Standard beinhaltet zahlreiche solcher Diagramme. Natürlich ist es sinnvoll und entspricht dem Grundgedanken von DA, für die jeweils gegebene Situation zu überlegen, ob man Optionen ergänzt oder streicht und ob man diese anders bewertet als es hier erfolgt ist. Idealerweise sollte in einem Unternehmen, das agil arbeitet, die Weiterentwicklung solcher Diagramme Teil der Organisationsentwicklung sein.
Wer jetzt motiviert ist, sich mit Disciplined Agile näher zu beschäftigen, findet hier die weiterführenden Links:
Homepage Discipline Agile
Wenn wir ein agiles Framework wie Scrum betrachten, so startet die Entwicklung mit einem Backlog, einer Liste von zu erledigenden Aufgaben. Im Scrum-Guide wird neutral von Backlog-Items gesprochen; in der Scrum-Praxis sind das immer noch User-Stories. User-Stories sind allerdings nur eine Möglichkeit, Anforderungen zu definieren. Als Einstieg sicher sehr praktisch, da sie bewusst in Anwender-Sprache und Anwender-Denke formuliert sind. Dass im weiteren Verlauf eines Projektes detailliertere Spezifikationen notwendig sind und dafür andere Formate als User-Stories notwendig sind, werde ich in einem späteren Newsletter behandeln. Hier beschränke ich mich auf den Hinweis, dass eine Liste von Anforderungen in Anwender-Sprache bei weitem nicht ausreicht, um die Anforderungen an eine IT-Anwendung ausreichend zu beschreiben. Für nicht-funktionale Anforderungen sind sie unpraktisch. Anstatt: Maximale Antwortzeit 1 Sekunde für 90 % der Transaktionen, könnte man natürlich eine User-Story schreiben, die so lauten könnte: „Als Anwender des Systems möchte ich in 90 % der Fälle ein Ergebnis innerhalb einer Sekunde ab Abschluss der Dateneingabe angezeigt bekommen, damit ich nicht zu lange warten muss.“ Also im Ernst: wo ist hier der Mehrwert einer User-Story? Gleiches könnte ich auch für Anforderungen an Schnittstellen zu externen Systemen, an Usability-Features etc. argumentieren.
Während für nicht-funktionale Anforderungen User-Stories „nur“ unpraktisch sind, gibt es in anderen wichtigen Themenfeldern Lücken, die den Erfolg von IT-Projekten massiv gefährden. Ein IT-Projekt besteht aus viel mehr als der Software-Entwicklung, wie sie mit Scrum oder XP beschrieben und gestaltet wird. Die frühen Phasen eines IT-Projektes sind mein heutiges Thema. Damit stelle ich nicht den Wert von Scrum, XP oder Lean für die Entwicklungsphase selbst infrage, will aber auf die notwendigen Vorbereitungsaktivitäten hinweisen.
Ein Vorgehensmodell, das den vollständigen Lebenszyklus eines Projektes abdeckt, ist DSDM (Dynamic System Development Method), das seit einigen Jahren unter dem weniger sperrigen Namen Agile Business Consortium (ABC) firmiert. Für Mitglieder stehen dort umfangreiche Dokumente inklusive Templates zur Verfügung, aus denen ich hier auszugsweise zitiere. Hier zunächst die Übersichtsgrafik, auf die ich mich in der Folge beziehe. Übrigens war Arie van Bennekum als Vertreter von DSDM im Jahr 2001 einer der 17 Autoren und Unterzeichner des Agilen Manifests.
Vorgehensmodell DSDM (© Agile Business Consortium)
Dieses Modell macht deutlich, dass auch bei agilen Projekten eine angemessene Planungsphase (Machbarkeit, Grundlagen) vorzusehen ist, bevor eine Umsetzung in Iterationen bzw. Sprints startet. Ebenso sind beim Projektabschluss die erforderlichen Berichts- und Dokumentationspflichten zu erfüllen. Die „evolutionäre Entwicklung“ kann sich an Scrum, XP oder Lean orientieren, das konkrete Setup ist in der Phase „Foundations“ (Grundlagenplanung) zu erarbeiten. Ich kenne kein anderes Vorgehensmodell, das ein solches Vorgehen so klar, einfach und praxisgerecht darstellt.
Es gibt für jede Phase ein oder mehrere ausführliche Templates. Ich finde es auch elegant, dass die Templates nicht Formulare mit mehr oder minder selbsterklärenden Überschriften sind, sondern zu jedem Punkt ausführlich und auch anhand von Beispielen erläutert wird, welche Inhalte an dieser Stelle zu erarbeiten sind.
Für alle, die meinen, von DSDM noch nichts gehört zu haben, möchte ich die Priorisierung von Anforderungen nach dem MoSCoW-Modell erwähnen, die von DSDM stammt. MoSCoW ist ein mit dem Vokal o angereichertes Akronym für Must, Should, Could, Won’t.
In der Vor-Projekt-Phase geht es darum, die Entscheidung zu treffen, ob ein Projekt gestartet wird und die Ziele festzulegen. Es sind die typischen Aufgaben eines Projekt-Portfolio-Managements, die hier nicht weiter erläutert werden müssen.
Die Machbarkeitsstudie ist kein Spezifikum dieses Vorgehensmodells, wird aber in den agilen Frameworks nicht explizit genannt. Auch bei SAFe, wo man es am ehesten erwarten würde, sind solche Überlegungen nur partiell an verschiedenen Stellen vorgesehen, so unter dem Titel „Lean Business Case“ und als Teil des PI-Planning-Events. Ich finde es logisch und geradezu zwingend, eine Machbarkeitsstudie vor dem Start eines Software-Entwicklungsprozesses durchzuführen. Das ganz im Sinne des Postulats Nr. 10 des agilen Manifests, dass „die Kunst, die Menge nicht getaner Arbeit zu maximieren“, essenziell ist.
Im DSDM-Template für die Machbarkeitsstudie wird deren Soll-Ergebnis so beschrieben (von mir übersetzt, gekürzt und bearbeitet):
Auf Grundlage der Machbarkeitsstudie ist wieder eine Entscheidung über das weitere Vorgehen zu treffen, einschließlich der Entscheidung, das Vorhaben nicht mehr weiterzuverfolgen. Wenn möglich, sind Lösungsvarianten bereits jetzt auszuscheiden, so z.B. der Einsatz von Standard-Software versus Individualentwicklung.
Meines Wissens in keinem anderen agilen Vorgehensmodell so klar gefordert und beschrieben ist der nächste Schritt, die Grundlagenplanung. Deren Lieferobjekte sind (von mir übersetzt, stark gekürzt und bearbeitet):
Auch hier ist wieder zu entscheiden, ob und wie mit dem Projekt weiter verfahren wird. Es kann z.B. eine neuerliche Durchführung der Grundlagenplanung mit geänderten Parametern beauftragt oder das Vorhaben gänzlich verworfen oder neu aufgesetzt werden.
Wenn nach diesen Vorbereitungsarbeiten ein Umsetzungsprojekt beauftragt wird, so ist diese im Verständnis des ABC immer eine iterative Entwicklung (sie wählen den in der IT-Branche nicht vorbelasteten Begriff „evolutionär“). Diese kann verschiedene Vorgehensmodelle kombinieren und es wird so gut wie immer auch Teilprojekte geben, die am besten gemäß einem Wasserfallmodell abgewickelt werden, weil das gewünschte Ergebnis hinreichend klar definiert werden kann. Das gilt immer für die Beschaffung von Lizenzen und Infrastruktur, aber auch für den Zukauf von Leistungen externer Partner, für die ein klassischer Werkvertrag mit allen damit verbundenen Vorteilen geschlossen werden kann.
Die Post-Projekt-Phase
Je nach Umfeld eines Projektes und den spezifischen Gegebenheiten sind nach erfolgtem Deployment eine Reihe von Aktivitäten erforderlich, deren Relevanz bei agilen und nicht-agilen Projekten gleich ist.
Ich habe dazu den AI-Chatbot von PMI (PMI Infinity) befragt und folgende Antwort bekommen (das gleich als Hinweis auf dieses großartige Angebot von PMI, gratis für alle Mitglieder):
Hier sind einige wichtige Aktivitäten, die zum Abschluss eines Projekts erforderlich sind:
Diese Aktivitäten können je nach Art und Umfang des Projekts variieren. Es ist wichtig, dass alle Aktivitäten sorgfältig geplant und durchgeführt werden, um sicherzustellen, dass das Projekt erfolgreich abgeschlossen wird.
Mein Bezug auf PMI im vorherigen Abschnitt sollte schon zeigen, dass das Vorgehensmodell des Agile Business Consortiums (ABC) sich gut mit dem Standard von PMI verträgt. PMI hat immer schon und nach wie vor den gesamten Lebenszyklus von Projekten im Fokus. Wieder habe ich PMI Infinity befragt und folgende Antwort erhalten:
Diese Phasen bilden den klassischen Projektmanagement-Lebenszyklus:
DSDM differenziert die Planungsphase in Machbarkeitsstudie und Grundlagenplanung, was eine sinnvolle Unterteilung ist, bei kleineren Projekten aber auch in einem Schritt erledigt werden kann. Auch die Durchführungsphase wird bei DSDM in Evolutionäre Entwicklung und Deployment unterteilt.
Diese Querverweise von DSDM auf PMI sollen demonstrieren, dass verschiedene Frameworks unterschiedliche Schwerpunkte setzen und man daher mehr als ein Framework kennen und nutzen sollte. PMI stellt zweifellos den umfassendsten Ordnungsrahmen zur Verfügung, der eine projektspezfische Anpassung (Tailoring) ausdrücklich vorsieht und fordert. Dafür bietet DSDM eine Fülle an wertvollen Inhalten.
Nach einem durchaus aufwändigen Zertifizierungsprozess darf ich mich übrigens als „Agile Business Catalyst“ bezeichnen, also als jemand, der qualifiziert ist, die Anwendung von DSDM als Berater und Coach zu unterstützen.
In diesem Beitrag habe ich mich auf die Vorbereitungsphase von agilen Projekten konzentriert und die Impulse vorgestellt, die ABC dazu bietet. ABC stellt über die oben genannten Templates hinausgehend umfangreiches Material zur Verfügung, so z.B. auch Vertragsmuster, Checklisten und Planungsdokumente für Planung, Reviews, Abnahmen etc. Ich kann die Mitgliedschaft bei ABC für Personen oder auch für Organisationen sehr empfehlen.
Wir schätzen „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung“, so lautet der dritte Punkt des agilen Manifests. Diese Aussage wird in der Praxis sehr unterschiedlich interpretiert.
Interessant ist, dass hier vom Kunden (im englischen Original auch „Customer“) die Rede ist, die gängigen agilen Standards aber die Frage, in welchem Rechtsverhältnis der Kunde zu seinem Gegenüber steht, völlig außen vor lassen.
Im Scrum-Guide kommt das Wort „Kunde“ nicht vor. Es gibt das Scrum Team und das „besteht aus einem:einer Scrum Master:in, einem:einer Product Owner:in und Developer:innen. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien“. Und weiter: „Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt“. Daraus könnte man schließen, dass ein Product Owner den Kunden repräsentiert, denn der Wert eines Produkts kann nur durch seine Nutzung und den daraus resultierenden Nutzen für den Kunden ermittelt werden. Die Software als solche kann technisch hervorragend sein, die Architektur bzw. der Code kann elegant sein usw., ohne die Nutzung in einem konkreten Anwendungskontext („Business Case“) kann der „Wert des Produkts“ nicht bestimmt werden.
Ein IT-Unternehmen, das sich auf Scrum als Standard beruft, definiert die Rolle Product Owner so: „Mitarbeiter:in des Kunden, der:die die inhaltliche Verantwortung für den Backlog trägt und alle Aufgaben erfüllt, in denen der Kunde als verantwortlich genannt wird“. In diesem Fall und bei allen größeren Projekten handelt es sich regelmäßig um zwei getrennte Unternehmen, in denen jeweils ein Management für den Unternehmenserfolg verantwortlich ist. Der Umsatz des einen sind die Kosten des anderen, insofern gibt es ein natürliches Spannungsverhältnis. Wenn der Scrum Guide also Subteams und Hierarchien innerhalb des Scrum Teams ausschließt, bleibt das Vertragsverhältnis zwischen Auftraggeber und Auftragnehmer offen. Es wird auch eine Harmonie zwischen den beteiligten Personen (bzw. deren Rollen) vorausgesetzt, die nicht immer gegeben ist, nicht einmal unter den Mitgliedern ein und desselben Unternehmens. Manchmal soll es sogar Spannungen und Konflikte zwischen den Abteilungen eines Unternehmens geben, wurde mir berichtet .
Das Scrum-Team scheint sich auf wundersame Weise von seiner Umwelt zu isolieren, die durch eine Vielzahl rechtlicher Regelungen bestimmt wird. Das sehe ich als die beste Erklärung für den überwältigenden Erfolg von Scrum, denn es wird hier ein Paradies für Entwickler:innen geschaffen. Es gibt keine Deadlines, keine Budgets, keine vordefinierten Geschäftsprozesse etc. Wer wünscht sich das nicht? Wolfram Müller verdanke ich die Erkenntnis, warum mit Scrum bessere Ergebnisse erzielt werden als mit traditionellen Vorgehensweisen: Scrum schützt diejenigen, die etwas von der Sache verstehen, vor Störungen durch ein Management, das einflussreich ist, aber nichts von der Sache versteht. Viel erfolgreicher wären wir aber, wenn die Entwicklungsarbeit in ein förderliches Managementumfeld eingebettet wäre.
Nun gehe ich hier nicht auf die Frage ein, was ein förderliches Management ausmacht, das ein anderes Mal. Ich frage nach den vertraglichen Rahmenbedingungen eines agilen Projekts. Ich bin kein Jurist, sondern Projektmanager, habe aber im Laufe meines Berufslebens mit hervorragenden Juristen zusammenarbeiten dürfen und viel von ihnen gelernt. Ich habe aber auch negative Erfahrungen gemacht, aus denen ich gelernt habe, wie man es nicht machen sollte.
Grundlegende Erkenntnis frei nach Paul Watzlawick: Es gibt immer einen Vertrag. Verträge sind nicht an die Form gebunden, sie entstehen auch durch mündliche Vereinbarungen, heute durch Mails oder auch durch die geübte Praxis („konkludente Handlungen“). Bei allen größeren Projekten gibt es jedoch einen schriftlichen Vertrag, und sei es nur ein Angebot, das vom Auftraggeber angenommen wurde. Die Frage ist, ob der Vertrag die Projektarbeit unterstützt oder behindert.
Hier gibt es eine Reihe von Praktiken, die je nach Kontext mehr oder weniger gut funktionieren:
a. Wir schließen nach wie vor klassische Werkverträge ab, handhaben sie aber nicht so streng. Die Schwelle für die Notwendigkeit von Change Requests wird angehoben, das Ergebnis wird akzeptiert, wenn es funktioniert, auch wenn es von der ursprünglichen Anforderungsdefinition abweicht.
b. Wir schließen Verträge mit reiner Aufwandsverrechnung ab, starten mit Anforderungen der Kategorien „Vision“ und „Epic“ und einer Budgetierung, die auf einer groben Aufwandsabschätzung auf Basis von Erfahrungswerten basiert.
c. Wir mischen die beiden Ansätze bis hin zum „agilen Festpreis“, den ich als Wunder bezeichnen würde, wenn er tatsächlich das wäre, was er vorgibt zu sein.
Aus der Praxis kann ich berichten, dass jeder der genannten Ansätze funktionieren kann, wenn die Rahmenbedingungen stimmen. Das mag überraschen, ist aber so. Problematisch wird es erst, wenn ein Vertrag abgeschlossen wird, der nicht zum Projektansatz passt, und – das ist das Entscheidende – wenn er dann auch noch exekutiert wird.
Die umfassendste Darstellung relevanter Vertragsinhalte mit beispielhaften Musterverträgen, die mir bekannt ist, stammt vom Agile Business Consortium und steht dessen Mitgliedern zur Verfügung. Hier eine komprimierte Liste der dort genannten Vertragsinhalte.
1. Definitionen: Klärung von Begriffen und Interpretationen, um Missverständnisse zu vermeiden.
2. Vorgehensmodell: Festlegung des agilen Ansatzes und der Zusammenarbeit zwischen den Parteien.
3. Leistungen: Beschreibung der zu erbringenden Dienstleistungen, einschließlich Beratung, Entwicklung/Customizing, Schulung und Produktlieferungen.
4. Machbarkeit: Vorgehen zur Bestimmung der technischen und finanziellen Machbarkeit des Projekts.
5. Grundlagenplanung: Schaffung eines grundlegenden Verständnisses der Geschäftsanforderungen, Definition der Lösungsarchitektur und Festlegung des Projektlebenszyklus.
6. Projektablaufplanung: Entwicklung eines Lieferplans, der während des Projekts weiterentwickelt werden kann.
7. Entwicklungsphase: Definition der Aufgaben des Lösungsentwicklungsteams und Entwicklung der Lösung in Iterationen.
8. Deployment: Überprüfung und Abnahme der entwickelten Lösungen vor der Inbetriebnahme.
9. Änderungsmanagement: Verfahren zur Anpassung der Projektanforderungen und des Lieferplans.
10. Projektmanagement: Definition der Projektorganisation und der Schlüsselrollen im Projekt.
11. Personal: Anforderungen an das Personal, einschließlich Qualifikationen, Verfügbarkeit und Maßnahmen im Falle von Ausfällen.
12. Vergütung: Festlegung der Vergütung und der Zahlungsbedingungen für die erbrachten Leistungen.
13. Vertraulichkeit: Umgang mit vertraulichen Informationen und deren Schutz.
14. Datenschutz: Umgang mit personenbezogenen Daten gemäß den gesetzlichen Bestimmungen.
15. Gewährleistung: Zusicherungen und Verpflichtungen des Auftragnehmers.
16. Geistiges Eigentum: Regelungen zu Rechten an geistigem Eigentum, die während des Projekts entstehen oder von einer der Parteien in das Projekt eingebracht wurden (z.B. Standardsoftware).
17. Haftung für Schutzrechte: Entschädigung bei Verletzung von Rechten an geistigem Eigentum Dritter.
18. Haftungsbeschränkung: Begrenzung der Haftung der Parteien.
19. Versicherung: Verpflichtung zum Abschluss und Aufrechterhaltung einer angemessenen Versicherung.
20. Laufzeit und Beendigung: Regelungen zur Laufzeit und Beendigung des Vertrags, einschließlich der Folgen der Beendigung.
21. Streitbeilegung: Verfahren zur Beilegung von Streitigkeiten, einschließlich Schlichtung, Mediation und Gerichtsverfahren.
22. Kommunikation: Anforderungen an die Kommunikation zwischen den Parteien.
23. Allgemeine Bestimmungen: Verfahren zur Abänderung des Vertrages, Rechte von Dritten, Umgehen mit höherer Gewalt, Abwerbeverbot etc.
Viele dieser Punkte unterscheiden sich nicht voneinander, egal nach welchem Paradigma man ein Projekt abwickelt, sie sind in einem agilen Projekt genauso zu regeln wie in einem Wasserfallprojekt, nur eben inhaltlich unterschiedlich.
Seit fast einem Jahr bin ich Solution Partner von agile.agreement, einem Netzwerk, dessen Gründer in der Schweiz tätig sind. Unsere Überzeugung ist, dass Projektverträge in hohem Maße von erfahrenen Projektmanager:innen bestimmt werden müssen. Es braucht eine interdisziplinäre Zusammenarbeit auf Augenhöhe mit Jurist:innen, die für die korrekte „handwerkliche“ Umsetzung unverzichtbar sind und die auch eine Reihe von Regelungen treffen müssen, für die wir als Projektmanager:innen keine Expertise beanspruchen können. Ein Blick auf die obige Liste der relevanten Vertragsinhalte sollte deutlich machen, was ich jeweils wie zuordne.
Die Mitglieder von agile.agreement vereinen eine Fülle von praktischen Erfahrungen mit agilen Projekten. Diese sind in einem „agile.agreement Canvas“ verdichtet und mit Best Practices unterlegt. Wir geben agilen Teams – gemeinsam mit darauf spezialisierten Jurist:innen- den notwendigen und passenden vertraglichen Rahmen.
Gemeinsam mit einem der Gründer von agile.agreement, Michael Arm und mit Gernot Silvestri, meinem langjährigen Freund und oftmaligen Partner in anspruchsvollen Projekten, habe ich am 25. Juni 2024 ein Webinar durchgeführt, bei dem wir unsere wichtigsten Erkenntnisse aus mehreren Jahrzehnten Berufspraxis zur Diskussion stellten.
Hier geht es zur Aufzeichnung.
Ein Kollege, den Tom DeMarco wohl als Adrenalin-Junkie klassifiziert hätte, sagte immer: „Sieger erkennt man am Start!“ Klang überzeugend und sollte wohl alle motivieren, mit Elan an jede neue Herausforderung heranzugehen.
Im ersten Moment dachte ich mir auch, das sei ein gutes Statement, aber bald kamen die Zweifel. Als Marathonläufer weiß ich, dass ein zu hohes Tempo am Start fatal ist. Ich starte immer mit regelmäßigem Blick auf die Pulsuhr, denn wenn alle lospreschen, verliert man das Gefühl für das wahre Tempo. Gute Marathonläuferlegen zwei gleich schnelle Hälften hin, idealerweise wird man sogar etwas schneller. Ich kann das aus eigener Erfahrung bestätigen, meine persönliche Marathon-Bestzeit habe ich erzielt, als ich in der zweiten Hälfte um nur 24 Sekunden langsamer war als in der ersten.
Projekte sind durchaus mit einem Marathon zu vergleichen, es kommt darauf an, mit einem optimalen Tempo zu starten, dieses durchzuhalten und idealerweise am Ende noch Reserven zu haben. Am Start kann man nicht erkennen, ob jemand dieses Kriterium erfüllt, man weiß es erst beim Zieleinlauf ganz genau, denn auch auf den letzten Kilometern kann noch was schiefgehen, oft genug habe ich Läufer mit Krämpfen wenige Kilometer vor dem Ziel gesehen, das ist die Höchststrafe.
Gut damit vergleichbar ist es, wenn ein Projekt beim Go-Live ins Straucheln kommt. Wenn es schon während der Projektlaufzeit geholpert hat, kann man ja Wetten abschließen, dass das Ende jedenfalls nicht besser sein wird. Es kommt aber auch bei gut laufenden Projekten vor, dass es am Ende so richtig holpert. Ich habe aus meiner Erfahrung einige typische Probleme in der Schlussphase von Projekten zusammengefasst, hier der Beitrag „Wie man beim Go-Live nochmals in Straucheln kommen kann“.
Es ist gut, diese potenziellen Stolperfallen schon am Start im Auge zu haben und während des Projektes nicht aus dem Auge zu verlieren. Man kann allerdings auch fragen: Was ist ein erfolgreiches Projekt? Der Schiefe Turm von Pisa, die Entdeckungsfahrt von Christoph Kolumbus, Apollo 13 und in der letzten Zeit auch die Elbphilharmonie sind Projekte, die ganz anders geendet haben, als im Projektauftrag stand, trotzdem kann man nicht sagen, dass sie gescheitert sind. Mit dieser Frage habe ich mich ganz allgemein in einem Vortrag beschäftigt, diesen gibt es als Video. Das Thema dieser Mail adressiere ich ganz am Anfang es Vortrages, aber natürlich freue ich mich, wenn auch der Rest interessiert.
Speziell mit der Elbphilharmonie habe ich mich etwas ausführlicher beschäftigt und die Geschichte sowie die Ursachen der Probleme und schließlich auch den Weg zum guten Ende beschrieben.
Wenn am Ende manches nicht klappt, kann das auch einfach Pech sein. Es gibt äußere Umstände, die auch mit der besten Planung und dem kompetentesten Projektmanagement nicht vorhergesehen und verhindert werden können. Aber ein oft eindeutig selbst verschuldeter Faktor, der ein Projekt ins Straucheln bringt, sind ungeeignete Verträge. Hier glauben viele Auftraggeber und ihre Anwälte, dass erfolgreiche Vertragsverhandlungen dadurch definiert sind, dass man möglichst viel durchgesetzt hat. Dass man also dem Auftragnehmer umfassende Pflichten auferlegt und ihm möglichst viele Risiken überbunden hat. Man glaubt also, den Sieger am Start schon erkennen zu können.
Aber: Abgerechnet wird am Schluss. Scheinbar erfolgreiche Vertragsverhandlungen können die unmittelbare Ursache für Probleme sein. Dazu habe ich einen ausführlichen Blog-Artikel geschrieben.
Wer dazu mehr erfahren möchte, ist herzlich eingeladen, die Aufzeichnung meines Webinars vom 25. Juni 2024 anzusehen.
Vertrauen ist die Grundlage erfolgreicher Arbeit in agilen Projekten, das wird immer wieder betont. Ich meine, es ist überhaupt die Grundlage für jede Art der erfolgreichen Zusammenarbeit, ob in Linienfunktionen oder in Projekten, unabhängig von Inhalt und Vorgehensmodell.
Ich finde nach wie vor die Definition von Julian Rotter aus dem Jahr 1967 am prägnantesten. Er bezeichnet Vertrauen als „generalisierte Verhaltenserwartung“, die über spezifische Situationen und Personen hinweg gilt. Diese Erwartung beinhaltet die Annahme, dass Personen und Organisationen ihre Zusagen einhalten, dass sie sich an Vereinbarungen und allgemeine Verhaltensnormen halten, auch wenn es für sie mit Aufwand oder Nachteilen verbunden ist und das auch, wenn sie die Möglichkeit hätten, anders zu handeln.
Rotter hat viele ergänzende Fragen untersucht. So etwa, ob vertrauensvolle Menschen einfach naiv oder weniger intelligent sind, was nicht bestätigt werden konnte.
Interessant ist, dass in einer groß angelegten Simulationsstudie von Robert Axelrod zur erfolgreichsten Strategie im Gefangenendilemma sich „TIT for TAT“ durchgesetzt hat. Diese Strategie besteht einfach darin, zunächst immer zu kooperieren, also zu vertrauen und danach immer das zu tun, was das Gegenüber getan hat.
Vertrauensvoll zu sein, ähnelt dem Konzept der Unschuldsvermutung: Vertrauensvolle Menschen gehen davon aus, dass sie vertrauen können, solange bis diese Annahme widerlegt wird. Ähnlich ist ja auch der Vertrauensgrundsatz in der Straßenverkehrsordnung angelegt. Nicht vertrauensvolle Menschen hingegen hegen einen Generalverdacht, rechnen a priori damit, dass sie nicht vertrauen können.
Es würde in diesem Kontext zu weit führen, auf die psychologische und spieltheoretische Forschung zum Thema Vertrauen näher einzugehen. Ich habe in einer Seminarunterlage meine Schlussfolgerungen für die berufliche Praxis ausführlich beschrieben.
Ich finde es wichtig, zwei Arten von Vertrauen zu unterscheiden. In Analogie zum Kommunikationsmodell von Watzlawick, das Sach- und Beziehungsebene unterscheidet, sind dies:
Die Hochseilakrobaten im Titelbild dieses Beitrages geben uns ein gutes Beispiel: Der fliegende Akrobat muss darauf vertrauen, dass der Fänger ihm nichts Böses will. Das ist aber sehr selten das Problem, nicht einmal in Krimis. Kritisch ist das Vertrauen auf der Sachebene, ob der Fänger also generell und gerade jetzt in der Verfassung ist, ihn zuverlässig aufzufangen, auch wenn die Flugbahn nicht ideal verläuft. Genau so ist es auch in Projektteams: Man benötigt Sachkompetenz und persönliche Integrität.
Während in vielen Organisationen die Sachkompetenz als Auswahlkriterium für Mitarbeiter*innen überbewertet wurde, beobachte ich in den letzten Jahren eine Übertreibung in die andere Richtung: die Teamfähigkeit, das Mindset wird so stark betont, als könnte jemand mit hoher Motivation jede Aufgabe erfüllen. Das ist – leider – nicht der Fall. Auch ein Team von „netten“ und hoch motivierten Leuten kann ein Projekt in den Sand setzen.
Nach meiner Erfahrung ist das Vertrauen in die Angemessenheit der Aufwände des Realisierungspartners ein entscheidender Erfolgsfaktor. Das Aushandeln des Verzichts auf Features, um das Budget und den Endtermin zu halten, funktioniert nur, wenn die vom Auftragnehmer geschätzten Realisierungsaufwände vom Auftraggeber als angemessen und nachvollziehbar gesehen werden.
Als überhöht empfundene Aufwände können auf unklare Vorgaben, mangelhafte Mitwirkungsleistungen des Auftraggebers, Schnittstellenprobleme etc. zurückzuführen sein und sind in Wirklichkeit daher angemessen. In der Praxis werden diese allerdings meist als Indikator für eine unfaire Preisgestaltung des Auftragnehmers interpretiert und belasten das Vertrauen auf der Beziehungsebene. Konflikte, gegenseitige Vorwürfe und Schuldzuweisungen sind die Folge und eine Negativspirale wird in Gang gesetzt.
Aber auch das Vertrauen auf der Sachebene ist für eine positive Zusammenarbeit in agilen Projekten wichtig. Entsteht der Eindruck, dass Mehraufwände durch ungenügend qualifizierte Mitarbeiter*innen, mangelhafte Projektsteuerung und Koordination entstehen, leidet auch dadurch die Effizienz der Projektarbeit.
Wenn die Voraussetzungen für einen Werkvertrag mit Fixpreis gegeben sind, spielt Vertrauen keine so große Rolle. Durch das Einholen von mehreren Angeboten kann die Angemessenheit des Preises hinreichend abgesichert werden. Durch die Vereinbarung des Fixpreises und zusätzlich durch Pönalen, einen Haftrücklass und andere vertragliche Vereinbarungen kann sich der Auftraggeber relativ gut gegen unliebsame Überraschungen absichern.
Ein agiles Projekt mit einem nur grob beschriebenen Leistungsinhalt und Leistungsumfang eignet sich aber nicht für das Einholen von belastbaren Vergleichsangeboten. Letztlich muss nach Aufwand abgerechnet werden. Auch der „Agile Festpreis“ ist bei genauem Hinsehen eine Abrechnung nach Time&Material mit einer Reihe von Kontroll- und Korrekturmechanismen.
Bei der Auswahl von Lösungsangeboten, in der Regel ist das eine Kombination von Produkten und Dienstleistungen, wird meiner Erfahrung nach leicht bewertbaren Kriterien zu großes Gewicht zugestanden. In öffentlichen Ausschreibungen erfolgt das allein schon als Absicherung gegen Einsprüche der unterlegenen Bieter, die bei „weichen“ Faktoren wie z.B. „Vertrauenswürdigkeit“ mit hoher Erfolgswahrscheinlichkeit die Zuschlagsentscheidung bekämpfen könnten.
Gerne bewertet man eine Präsentation oder führt Assessments für Teams durch. Solche Momentaufnahmen sind an sich schon wenig aussagekräftig. Zusätzlich sind diese dadurch verfälscht, dass die besten Leute in diesen Phasen eingesetzt werden, diese aber während des Projektverlaufes nicht mehr oder jedenfalls nicht im erwarteten Ausmaß präsent sind.
Für den Erfolg ist aber entscheidend, dass der Auftraggeber dem Auftragnehmer sowohl auf der Sach- als auch auf der Beziehungsebene vertraut. Das nicht nur bei Auftragserteilung, sondern über die gesamte Dauer eines Projektes und gerade bei auftretenden Problemen.
Ob andere Personen vertrauensvoll sind und ob wir ihnen vertrauen können, entzieht sich weitgehend unserem Einfluss. Vertrauensbildung muss daher beim eigenen Verhalten ansetzen. Wenn ich als Projektleiter*in meinen Teammitgliedern vertraue, ihnen etwas zutraue, meine Zusagen halte und generell nach dem Motto „Walk your Talk“ lebe, hat das positive Auswirkungen auf das Vertrauensniveau im Team. Der Erfolg ist nicht garantiert, aber ohne dieses Investment gibt es jedenfalls keinen Erfolg.
Um auch das Vertrauen auf der Sachebene zu fördern, ist es wichtig, dass die richtigen Skills im Team vertreten sind und die Teammitglieder so eingesetzt werden, dass sie eine realistische Chance haben, ihre Aufgaben zu bewältigen. Anspruchsvolle Aufgaben können aber nicht ohne Fehler bewältigt werden. Der Umgang mit Fehlern, die „Fehlerkultur“ ist einer der wirkungsvollsten Hebel für den Aufbau von Vertrauen in beiden Dimensionen. Was eine solche förderliche Kultur ausmacht, hat Gerhard Zeiler, der frühere Chef des ORF und der RTL Group, nun Präsident von Turner International, auf den Punkt gebracht: „Der Sieg gehört dem Team, die Niederlage gehört dem Chef.“ Seine Erfolge zeigen, dass mit diesem Zugang alle gewinnen.
Vertrauen macht nicht nur Projektarbeit erfolgreicher. Untersuchungen auf volkswirtschaftlicher Ebene deuten darauf hin, dass ein höheres Niveau an Vertrauen sich günstig auf den Wohlstand einer Nation auswirkt. Für alle, die es genauer wissen wollen, hier der Link zu einer Studie von Forschern des MIT.
Der Erfolg des IT-Einsatzes ist gegeben, wenn die Anwender damit effektiver und effizienter arbeiten können als vorher. Alle IT-Systeme sind in diesem Sinne Werkzeuge, die im Rahmen der Geschäftsprozesse angewendet werden. Dass die IT diese Werkzeuge entwickelt und betreibt, ist eine Dienstleistung gegenüber den Anwenderbereichen. Die IT, ob als Abteilung oder als Unternehmen innerhalb eines Konzernverbundes organisiert, agiert hier als Dienstleister.
Auch andere Bereiche eines Unternehmens erbringen Dienstleistungen für unternehmensinterne Leistungsempfänger, zum Beispiel das Rechnungswesen, der Personalbereich, das Facility Management.
Die Anwenderbereiche sind Kunden, sie bestellen Produkte und Dienstleistungen und bekommen diese entsprechend den Qualitäts-, Termin- und Kostenvorgaben von ihren internen Dienstleistern geliefert. So das Idealbild.
Die Anwenderbereiche selbst nützen die IT-Unterstützung zur Herstellung von Produkten und zur Erbringung von Dienstleistungen für ihre Kunden. Modernes Prozessmanagement sieht jeden Geschäftsprozess aus der Perspektive des Leistungsempfängers und es macht keinen Unterschied, ob dieser Teil desselben Unternehmens oder ein „echter“ Kunde ist. Jedes Unternehmen, jede Organisationseinheit, jede Person ist gleichzeitig Dienstleister und Empfänger von Dienstleistungen, also Kunde und Dienstleister je nach Situation. Insofern folgt aus einer Dienstleistungsbeziehung nicht automatisch ein generelles Autoritäts- und Prestigegefälle. Am Verhältnis von Vertrieb und Produktion kann man einen dauerhaft schwebenden und unauflösbaren Konflikt beobachten, welcher Bereich nun wessen Dienstleister ist.
Interessant sind Dienstleister-Kunden-Modelle bei qualifizierten Berufen, zum Beispiel Ärzten, Rechtsanwälten, Wirtschaftsprüfern und Steuerberatern. Hier wird klar, dass die Anordnungsbefugnis des Kunden an Grenzen stößt, weil es um die Verfügbarkeit von spezifischem Know-how geht, das dem Kunden fehlt. Der Kunde muss also in gewissen Bereichen den Empfehlungen des Dienstleisters folgen, will er nicht Schaden erleiden. Andererseits kann der Kunde (auch Klient oder Patient) diesem Dienstleister das Mandat entziehen und letztlich auch gegen dessen Rat handeln. Tut dies etwa ein Patient, so muss er ausdrücklich und nachweislich über die damit verbundenen Risiken aufgeklärt werden, was dann geschieht, fällt in seine Eigenverantwortung.
IT Abteilungen hatten und haben vielfach damit zu kämpfen, dass man ihnen keine vergleichbare Position zugesteht wie den genannten qualifizierten Dienstleistern. Obwohl das Business-Management betont, von IT nichts zu verstehen und viele sind darauf sogar stolz, erwarten sie von der IT-Abteilung die widerspruchslose Ausführung von Aufträgen. Das kann allerdings genau so ins Auge gehen, wie wenn ich meinen Kardiologen vorschreibe, ob er mir einen Stent setzen soll oder nicht.
In den Anfängen des IT-Einsatzes waren viele IT-Abteilungen alles andere als Dienstleister. Sie sagten den Anwendern, was zu tun sei, wie es zu tun sei und insbesondere was nicht möglich sei. Auch heute noch gibt es IT-Abteilungen, die von ihren Anwendern in erster Linie als Nein-Sager und Innovationshemmnis erlebt werden. Ein Übriges trägt dazu die bekannte Unzuverlässigkeit bei der Erfüllung von Terminen und bei der Einhaltung von Budgets bei, die in IT-Projekten geradezu regelmäßig auftritt. Die Quote an gescheiterten IT-Projekten, von der die Standish Group jedes Jahr im Chaos Report berichtet, bestärkt mit statistischen Daten dieses Image.
Das Verständnis der IT als Dienstleister war in vielen Unternehmen daher ein Versuch, sich aus dieser Abhängigkeit zu befreien. Wie so oft führten auch hier Befreiungsversuche oft zu überzogenen Reaktionen, die der IT eine untergeordnete, rein ausführende Rolle zuschrieben. Dieses Verständnis der Dienstleisterrolle kann für Commodity-Services wie den Betrieb eines Data-Centers oder die Wartung der Arbeitsplatzausstattung durchaus ohne Schaden für das Ergebnis praktiziert werden. Nicht zufällig werden solche IT-Leistungen outgesourct und die Leistungserbringung wird über standardisierte Verträge mit Service Level Agreements und mengenabhängigen Fixpreisen geregelt.
Unter dem Stichwort „Digitalisierung“ wird der umfassende Wandel und die Neugestaltung von Geschäftsmodellen, Produkten, Dienstleistungen und Arbeitsweisen durch den Einsatz digitaler Technologien beschrieben. Es geht dabei um eine tiefgreifende Transformation des gesamten Unternehmens oder wesentlicher Wertschöpfungsketten, nicht nur um die Optimierung einzelner Prozesse. Digitalisierung zielt darauf ab, durch den Einsatz neuer Technologien Wettbewerbsvorteile zu schaffen, die Kundenerfahrung zu verbessern und neue Geschäftsmodelle zu ermöglichen.
Mit der Digitalisierung wurde IT erstmals zur Sache des Top-Managements, sie ist nicht mehr nur ein Werkzeug zur Effizienzsteigerung oder gar nur ein Kostenfaktor, der so weit wie möglich zu reduzieren ist. Der IT-Einsatz ist zur unabdingbaren Voraussetzung für die Weiter- und Neuentwicklung von Geschäftsmodellen geworden. Ich kenne keine Top-Manager, die heute noch stolz verkünden, dass sie an IT nicht interessiert seien.
Unternehmen wie Amazon, Uber, Airbnb und natürlich Google und Facebook beruhen in ihrem Kern auf der Nutzung der Potenziale der Informationstechnologie. Hier ist offensichtlich der IT-Einsatz keine standardisierbare Dienstleistung, die man von einem zum Befehlsempfänger degradierten Dienstleister erbringen lässt, den man nach dem Kriterium des günstigsten Preises auswählt. IT ist hier die unverzichtbare Grundlage der gesamten Geschäftstätigkeit.
Mittlerweile gilt in immer mehr Branchen, dass die Nutzung der IT nicht mehr einseitig von den Anwenderbereichen definiert und dann angeordnet bzw. bestellt werden kann. Der Einsatz der IT muss im Dialog aller Unternehmensbereiche konzipiert werden. Es gibt keine Einbahnstraßen mehr: Die IT orientiert sich am Geschäftsmodell und den damit verbundenen Geschäftsprozessen. Die Anwenderbereiche wiederum reagieren auf Potenziale der IT und integrieren diese in neue Geschäftsprozesse und Geschäftsmodelle. Ein Vorgehen gemäß einem Wasserfall-Modell ist in solchen Settings kontraproduktiv. Es braucht einen Dialog und eine Zusammenarbeit auf Augenhöhe (siehe Grafik).
Anwenderbereiche und IT müssen gemeinsam an der Umsetzung der Unternehmensziele arbeiten. Die IT muss dafür sorgen, dass immer mehr Bereiche der IT-Services als standardisierte Services bereitgestellt werden. Diese Dienstleistung wird in einem optimierten Mix aus Eigen- und Zukaufleistungen erbracht. Durch das professionelle Management dieser Dienstleistungen schafft sich die IT die notwendigen Freiräume zur kreativen Mitwirkung an der Weiterentwicklung des Unternehmens. Durch eine hohe Qualität ihrer Beiträge schafft sich vor allem die unternehmensinterne IT-Organisation die notwendige Akzeptanz, um als Partner wahrgenommen zu werden. Alle Beteiligten nehmen ihre ureigenen Aufgaben mit Engagement und Qualität wahr und übernehmen dafür gegenüber der Geschäftsleitung gemeinsam die Verantwortung.
Die Anwenderbereiche sind dafür verantwortlich, ihre Geschäftsmodelle und Geschäftsprozesse zu optimieren und dabei auch disruptive Innovationen in Betracht zu ziehen. Diese Disruption kann durch Marktentwicklungen erzwungen oder ermöglicht werden, sie kann aber auch durch neue technische Optionen erzwungen oder ermöglicht werden. Die Anwendung von Künstlicher Intelligenz (KI) ist das aktuelle Beispiel. Auch wenn das aktuell alle Merkmale eines Hypes aufweist, können wir davon ausgehen, dass es eine nachhaltige Entwicklung ist. Das Aufzeigen von Optionen einer radikal geänderten Prozessgestaltung von Seiten der IT einerseits, die Innovationsbereitschaft und Kreativität des Business bei der Entwicklung von Geschäftsmodellen, die diese Chancen nutzen, kann nur durch so ein dialogisches Rollenmodell erreicht werden.
Ein Verharren in einem asymmetrischen Rollenmodell (Business schafft an, IT führt aus) ist eine existenzielle Gefahr für jedes Unternehmen und jede Organisation. Eine Kultur der partnerschaftlichen Zusammenarbeit muss entwickelt werden, sie erfordert Organisations- und Personalentwicklung. Das ist zu tun:
Fazit: Die digitale Transformation erfordert eine enge und partnerschaftliche Zusammenarbeit zwischen IT und Fachbereichen. Nur durch einen intensiven und wertschätzenden Dialog, ein klares Verständnis der gegenseitigen Rollen und die Schaffung einer Kultur des Vertrauens können Unternehmen und öffentliche Organisationen die Herausforderungen der Digitalisierung erfolgreich meistern.
Der Projektmanagement-Podcast von Thomas Wuttke ist ein Leuchtturm in der Projektmanagement-Community. Es war mir eine besondere Ehre und Freude, mit Thomas die Folge 200 seines Podcasts zu bespielen.
Hier das Ergebnis unseres Gesprächs, das auch von besonderer Heiterkeit gekennzeichnet ist.
Eine der Kernaussagen: „Standards geben Orientierung, aber der Erfolg liegt oft darin, die Regeln zu brechen und flexibel zu handeln.“
Vorbemerkung: Ich weiß, eine KI kann kein Urheberrecht beanspruchen. Aber wenn ich schon der Versuchung erlegen bin, den Visual Creator (Teil von MS Co-Pilot) zu bemühen, will ich das auch offenlegen. Die Nachbearbeitung (Zuschneiden auf das richtige Format) hat dann ChatGPT übernommen. Ich habe auch zum Inhalt einige Versuche mit diversen KI-Tools gemacht, aber das ergab Texte, die in der dafür typischen Weise richtig und gleichzeitig banal waren. Der nachfolgende Text ist daher – im Gegensatz zum Bild – nicht von einer KI generiert.
Die klassische Grundlage der Engpassorientierung ist das Minimumprinzip von Justus von Liebig, auch bekannt als das Minimumgesetz. Es besagt, dass das Wachstum von Pflanzen durch die im Verhältnis knappste Ressource eingeschränkt wird. Diese Ressource, auch Minimumfaktor genannt, kann ein Nährstoff, Wasser, Licht oder ein anderer essenzieller Faktor sein. Wenn ein Boden etwa zu wenig Phosphat enthält, kann man diesen Mangel nicht durch erhöhte Gaben von Stickstoff, Kalium usw. ausgleichen.
Diese Regel ist unmittelbar einleuchtend und man könnte fragen, was es in Zusammenhang damit zu erklären gibt und ob es überhaupt denkbar ist, dass jemand nicht entsprechend diesem Gesetz handelt. Tatsächlich ist es jedoch oft so. Salopp gesprochen verzettelt man sich, kämpft an Nebenfronten, erfasst nicht den Kern eines Problems etc. Das hat sowohl emotionale Gründe (man weicht einer unangenehmen Aufgabe aus) als auch rationale (man erkennt nicht, wo der Engpass liegt).
Der kritische Weg in einem Projektplan beschreibt die Abfolge von Aufgaben, die ohne Verzögerung abgeschlossen werden müssen, um das Projekt fristgerecht zu beenden. Jede Verzögerung bei Vorgängen auf dem kritischen Weg verschiebt den gesamten Zeitplan und das Projektende.
Das Konzept des kritischen Weges wurde von Eliyahu M. Goldratt weiter entwickelt und ist ein wesentlicher Bestandteil der Theory of Constraints (TOC). Zum Unterschied vom kritischen Weg, der die zeitlichen Abhängigkeiten der Aufgaben abbildet, berücksichtigt die „Critical Chain“ der TOC auch die Verfügbarkeit und Zuweisung von Ressourcen.
Die Theory of Constraints stellt strikte Regeln auf, um den Erfolg eines Projektes zu sichern. Das ist der Projektsteuerungsprozess der TOC:
Die Priorisierung von Aufgaben und die Zuordnung von Ressourcen wird also nicht dem freien Ermessen eines Projektmanagers, Product Owners oder Scrum Masters überlassen. Theoretisch gibt die TOC in jeder Situation klar vor, welche Ressourcenzuordnung zu treffen ist.
In der Praxis stellen sich allerdings zahlreiche Herausforderungen, die einer perfekten Umsetzung der TOC im Wege stehen. Das sind die aus meiner Sicht wichtigsten Hindernisse:
Die Engpasskonzentrierte Strategie (EKS) ist eine Strategielehre, die Wolfgang Mewes entwickelt und erstmals 1970 in einem umfangreichen Fernkurs dargestellt hat. Ich habe diesen Kurs in den 80-er-Jahren absolviert und er hat mich nachhaltig geprägt. Genaugenommen ist die EKS eine Meta-Strategie, also eine Anleitung, wie Strategien gestaltet werden sollen, um zum Erfolg zu führen.
Den ursprünglichen Fokus auf die Karriereplanung hat Mewes später erweitert und die EKS zu einer allgemeinen Strategielehre für Personen, Unternehmen und soziale Systeme aller Art ausgebaut. Seit 2008 liegen umfassende Werknutzungsrechte an der EKS bei Fredmund Malik, der diese in die MAS (Malik Alleinstellungs-Strategie) integriert hat. Eine allgemein zugängliche Darstellung der EKS liefert das Buch „Das große 1×1 der Erfolgsstrategie„, das mittlerweile in der 27. Auflage vorliegt. Es enthält eine Vielzahl von Fallbeispielen, in denen die bewusste und oft auch unbewusste Anwendung der EKS-Prinzipien zum Erfolg führte.
Die EKS enthält keine expliziten Aussagen zum Management von Projekten. Dennoch lassen sich aus der EKS Empfehlungen für das Projektmanagement ableiten. Für mich bietet die EKS einen Rahmen, der die TOC als eine unter bestimmten Voraussetzungen optimale Methode impliziert, nämlich dann, wenn ein Ressourcendefizit bei einer Aktivität am kritischen Weg der aktuelle Engpass ist.
Die EKS betrachtet alle sozialen und biologischen Systeme unter dem Gesichtspunkt der darin wirkenden Kräfte. Dies können Antriebs- oder Bremskräfte sein, ebenso Anziehungs- oder Abstoßungskräfte. Dieses Spiel der Kräfte zu erkennen und für die Erreichung der eigenen Ziele zu nutzen, ist das Grundprinzip der EKS.
In seinem Geleitwort zur 22. Ausgabe der „Erfolgsstrategie“ schreibt Wolfgang Mewes: „Die EKS ist die Lehre vom effektiven Einsatz jeder Art von Energien. Ihre Gesetze gelten systemübergreifend […]. Ob Sie Ihren Firmen- oder Abteilungserfolg, Ihr (Selbst‑)Management oder Ihre Karriere verbessern wollen: Sie müssen Ihre Kräfte bündeln und auf den kybernetisch wirkungsvollsten Punkt konzentrieren“.
Die zentrale Empfehlung der EKS ist die Konzentration der Kräfte auf eine möglichst eng umrissene und homogene Zielgruppe mit einem Nutzenangebot, mit dem das brennendste Problem der Zielgruppe adressiert wird.
Das brennendste Problem der Zielgruppe bezeichnet die EKS als externen Engpass, die Faktoren, die der Lösung des brennendsten Problems der Zielgruppe durch uns (egal ob einzelne Person, Team, Unternehmen, Projekt etc.) entgegenstehen als internen Engpass. Der externe Engpass hat immer Vorrang vor dem internen: „Denke stets extrovertiert, fokussiere nicht so sehr auf interne Probleme. Denn je besser man die Probleme und Engpasspässe der Zielgruppe löst, desto besser wird man auch seine eigenen Probleme lösen“ (Erfolgsstrategie, S. 29).
„Jedes vernetzte System hat einen kybernetisch wirkungsvollsten Punkt, von dem aus die Entwicklung des gesamten Systems gesteuert werden kann“ (Erfolgsstrategie, S. 25). „In vernetzten Systemen kommt es also nicht darauf an, möglichst große Kräfte einzusetzen, sondern die vorhandenen Kräfte auf den jeweils wirkungsvollsten Punkt zu richten“ (ibid., S. 26).
Dieser wirkungsvollste Punkt ist der Engpass, auch als Minimumfaktor bezeichnet; Mewes bezieht sich explizit auf Justus von Liebig. Der Minimumfaktor wechselt im Zeitverlauf, „der Engpass wandert“. Wenn z.B. in einem Projekt der aktuelle Engpass die Verfügbarkeit bestimmter Skills ist und man diesen Mangel beseitigt, ist der dann aktuelle Minimumfaktor vielleicht ein Planungsdefizit, um die Prioritäten des Einsatzes dieser zusätzlichen Ressourcen zu bestimmen. Ist dieser Minimumfaktor behoben, ist der neue Engpass z.B. das Vorliegen hinreichend detaillierter und mit dem Kunden abgestimmter Spezifikationen.
Ein weiteres EKS-Prinzip ist der Vorrang immaterieller vor materiellen Vorgängen. „In jedem sozialen System gibt es materielle und immaterielle Engpässe, die auf vielfältige Weise miteinander vernetzt sind. Nur wenn beide Ebenen betrachtet werden, kann sich das Unternehmen optimal entwickeln“ (Erfolgsstrategie, S. 34). Das mag reichlich esoterisch klingen, letztlich meint es aber das, was man – ich beschäftige mich hier mit Projekten – als Projektkultur bezeichnet. Die EKS sieht Unternehmen (und Projekte) als dynamische Systeme: „Spannungen (Wünsche, Bedürfnisse, Ängste, Visionen, Erwartungen, Probleme, Intuition) sind die Triebfeder menschlichen Handelns. Immer dann, wenn zwischen Ist‑ und Soll‑Zustand eine Differenz auftritt, erleben wir Spannungszustände, die uns zum Handeln und zu Verhaltensänderungen motivieren. Spannungen zeichnen sich dadurch aus, dass ihnen Energie innewohnt. … Spannungen wirken im Engpass immer am stärksten“ (Erfolgsstrategie, S. 36f).
„Der eigene Erfolg hängt nicht davon ab, wie hart man arbeitet und wie sehr man sich anstrengt, sondern davon, wie gut es gelingt, auch die im Umfeld vorhandenen Spannungen zum eigenen Vorteil zu nutzen“ (Erfolgsstrategie, S. 37). Das ist allerdings nicht als Aufforderung zu egoistischer Ausbeutung der Umwelt gemeint. Denn: „Je besser Sie die immateriellen Prozesse erkennen und beeinflussen, desto besser sind die materiell finanziellen Ergebnisse“ (S. 39). Und: „Je mehr man dazu beiträgt, die Probleme anderer zu lösen, desto mehr werden diese anderen ihre Energie und ihre Ressourcen auf Sie richten!“ (Erfolgsstrategie, S. 38).
Die Engpassorientierung besagt in diesem Beispiel, dass es nichts bringt, die mangelnden Spezifikationen und Planungen fertig zu stellen, solange die für die Erledigung notwendigen Skills nicht zur Verfügung stehen. Es ist also immer zuerst der Engpass (der Minimumfaktor, der kybernetisch wirkungsvollste Punkt) zu suchen und zu beseitigen.
Diese Aussage ist für die Praxis allerdings zu relativieren, da es Vorlaufzeiten gibt und man im Voraus selten genau bestimmen kann, wie lange die wirksame Umsetzung einer Maßnahme braucht und was die nächsten Engpässe sein werden. Es ist daher notwendig und sinnvoll, Maßnahmen zu setzen, die nicht den aktuellen, sondern den vermuteten nächsten oder übernächsten Engpass adressieren. Richtig ist allerdings auch in diesem Fall, dass die maximale Wirkung nur erzielt werden kann, wenn jedenfalls der aktuelle Engpass zuerst beseitigt wird.
In der EKS wird dieser Unsicherheit mit der Empfehlung einer „schiefen Schlachtordnung“ Rechnung getragen. In Anlehnung an diese militärische Taktik beschreibt Mewes damit die Empfehlung, nicht alles auf eine einzige Karte zu setzen, sondern mehrere Optionen zu verfolgen. Dabei allerdings jene mit deutlich höchster Priorität, die geeignet erscheint, den aktuellen Engpass zu beseitigen.
Generell kann man aus der EKS für Projekte ableiten: Ein Projekt lebt davon, dass es seiner Zielgruppe einen Nutzenanbietet. Das entspricht der zentralen Rolle des Business Case in allen Standards des Projektmanagements. Allerdings sieht die EKS diesen „materiellen“ Faktor nur als eine notwendige, aber nicht hinreichende Grundlage für den Projekterfolg.
Die EKS richtet das Stakeholdermanagement radikal an den Bedürfnissen der „Zielgruppe“ aus: „Entscheidend ist allein, welches Problem die Zielgruppe für ihr wichtigstes hält. Über die Lösung des größten Engpasses bieten sie der Zielgruppe den größten Nutzen. Nach Lösung des größten Engpasses müssen sie sich konsequent dem nächsten widmen“ (Erfolgsstrategie, S. 141).
Die Idee dahinter: Je attraktiver das Nutzenangebot eines Projektes ist, umso leichter wird es die erforderlichen Ressourcen (Know-How, Personal, Sach- und Finanzmittel) erhalten.
Das Vorgehensmodell zur Steuerung eines Projektes auf Basis der EKS sehe ich so:
1. Wer ist die relevante Zielgruppe, wer hat den höchsten Nutzen aus dem Projekt und ist auch bereit und in der Lage, dafür „zu zahlen“. Nur, wenn dieser Punkt positiv abgeschlossen werden kann, machen die weiteren Schritt Sinn. Wenn diese Frage zu keinem befriedigendem Ergebnis führt, muss das Projekt eingestellt bzw. nicht gestartet werden.
2. Was ist für diese Zielgruppe der Engpass? Wo besteht der größte Schmerz und was wäre der höchste Gewinn? Was ist also der externe Engpass?
3. Welche Umstände im Projekt be- oder verhindern es, den externen Engpass erfolgreich zu beseitigen? Was ist also der interne Engpass?
4. Was ist zu tun, um den internen Engpass zu lösen, so dass nachfolgend der externe Engpass beseitigt wird?
5. Wer kann was tun und bis wann? Aktion: Initiieren dieser Maßnahmen und laufendes Controlling der Umsetzung.
6. Reichen diese Maßnahmen aus? Wenn nein, weiter bei Punkt 4.
Der externe Engpass eines Projektes ist dessen Erfolg, also die Erfüllung des Projektauftrages. Allerdings ist nicht klar, ob eine Abweichung von den im Projektauftrag genannten Zielen wirklich das brennendste Problem der Auftraggeber ist.
Ich habe selbst in einem Projekt in einem vertraulichen Gespräch mit dem Auftraggeber erfahren, dass sein brennendstes Problem darin besteht, dass ein kommunizierter Fertigstellungstermin keinesfalls wieder verschoben werden darf, ich könne aber diesen Termin bestimmen. In einem anderen Projekt – zufällig mit dem selben Auftraggeber – gab es wiederum einen fixen Termin, dessen Versäumen den Wert des Projektes weitgehend vernichtet hätte. Noch mehr galt dies für ein Großprojekt zur Umstellung der Systeme eines Finanzdienstleisters auf den Euro, hier war der Termin 1.1.2002 absolut fix und dessen Nicht-Einhaltung hätte das Unternehmen existenziell gefährdet.
In jedem der genannten Fälle ergab sich aus dem externen Engpass ein jeweils spezifischer Mix von Maßnahmen. Diese hatten mehr mit Scope- und Stakeholdermanagement zu tun als mit der Optimierung des internen Ressourcenmanagements, auch wenn natürlich letztlich in einem IT-Projekt die Bereitstellung funktionierender Software das letztgültige Erfolgskriterium ist.
Nicht zufällig hat die Standish Group für die Beurteilung des Projekterfolges die Kriterien „OnBudget, OnTime, OnTarget“ durch die Kriterien „Valuable, OnGoal, Satisfactory“ ersetzt. Begründung: „We avoid penalizing a project for having an evolving target, which all projects have, even the very small ones“. Auch PMI hat die Erfolgsdefinition für Projekte in analoger Weise weiter entwickelt: ein erfolgreiches Projekt liefert einen Wert (Nutzen höher als Aufwand) und dieser wird von den relevanten Stakeholdern wahrgenommen und akzeptiert. Kurz formuliert: Erfolg ist „Value+Perception“.
Der interne Engpass liegt im Bereich der Prozesse und Ressourcen des Projektes. Als Suchraster für die Management-Prozesse eignen sich Standards wie z.B. die ISO 21500 bzw. der weitgehend identische, aber detailliertere PMBOK.
Die Produktionsprozesse in einem IT-Projekt umfassen die Softwareentwicklung bzw. das Customizing von Software. Hier kann der SWEBOK als Suchraster dienen. In anderen Bereichen sind je nach Verfügbarkeit andere Systematiken heranzuziehen.
Es werden immer Maßnahmen im Bereich der Ressourcen notwendig sein. Die Erweiterung des Projektteams und/oder der Austausch von Personen, Bereitstellung von Räumen, das Engagement von Beratern zur gezielten Behebung von Know-How-Defiziten, Maßnahmen zur Korrektur von Schwachstellen der Projektkultur etc. Was immer getan wird, Kriterium ist immer der Beitrag zur Behebung des internen Engpasses, der wiederum Mittel zum Zweck ist, um den externen Engpass zu beheben.
Wenn man das Wort Engpass im Kontext des Projektmanagements hört, denkt man natürlich sofort an die Theory of Constraints(TOC) und den daraus abgeleiteten Ansatz des Critical Chain Projektmanagements (CCPM). Die EKS ist eine in der Projektmanagement-Community kaum bekannte Denkschule.
Zu TOC und CCPM gibt es im projektmagazin eine hervorragende Sammlung von Fachbeiträgen in einem Spotlight. Ein ChatBot, der Fragen zu diesen Management-Ansätzen basierend auf qualitätsgesicherten Dokumenten beantwortet, wird vom Netzwerk BlueDolphin bereitgestellt, dem ich auch angehöre.
Aus der TOC abgeleitet gibt es eine Fülle sehr konkreter Instrumente, um die Produktivität von Projekten signifikant zu steigern. Wenn dies der relevante interne Engpass ist, um den externen Engpass zu lösen, ist man mit dem Instrumentarium des CCPM bestens bedient und die EKS hat hier nichts Vergleichbares zu bieten, weil sie in einem anderen Kontext entwickelt wurde.
Allerdings erinnert mich die CCPM an das Bonmot von Paul Watzlawick: Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel. Es ist richtig, dass in jedem Projekt früher oder später die Erhöhung der Produktivität (des „Durchsatzes“ in CCPM-Terminologie) zum internen Engpass wird, dessen Beseitigung Priorität hat. Und zweifellos ist die Reduktion des „Work in Progress“ und damit des Multitaskings dafür der richtige Ansatz. Aber meist müssen zuerst Engpässe in vorgelagerten Bereichen beseitigt werden, bis der Durchsatz zum internen Engpass wird. So gesehen sind EKS und CCPM keine Gegensätze, allerdings sollte die EKS als übergeordnete Sicht zur Identifikation des jeweils prioritären Handlungsfeldes eingesetzt werden.
Friedrich der Große hat einmal gesagt: „Ich brauche Generäle, die nicht nur tüchtig sind, sondern auch Fortune haben.“ Spaniens Teamchef hat schon lange sehr gute Arbeit mit seinem Team geleistet und am Sonntag hatte er auch das sogenannte „Glück des Tüchtigen“.
Diesen Text hätte ich auch geschrieben, wenn Spanien das Finale nicht gewonnen hätte, denn es genügt nicht, gut zu arbeiten, man braucht auch mehr oder weniger Glück dazu. Österreichs Teamchef Ralf Rangnick verfolgt einen ähnlichen Ansatz wie Luis de la Fuente und immerhin wurde Österreich damit Gruppensieger vor Frankreich und den Niederlanden, was vor der Euro niemand für möglich gehalten hat. Der Finalsieg Spaniens erspart mir allerdings die Frage, warum man von jemand lernen sollte, der am Ende verloren hat. Daher spreche ich nachfolgend nur noch über Spanien.
Der Ansatz von Luis de la Fuente kann meiner Ansicht nach durch eine grundlegende strategische Entscheidung und einige flankierende Taktiken beschrieben werden. Ich gehe auf die Definition von Strategie und Taktik hier nicht näher ein. Dazu gibt es einen ausführlichen Blogbeitrag, der die Unterscheidung von Strategie und Taktik im Kontext des Konfliktmanagements beschreibt.
Die Strategie: Offensiv statt defensiv
Anstatt vor allem gegnerische Tore zu verhindern und auf Fehler des Gegners zu warten, setzte Luis de la Fuente auf eine offensive Strategie. Dies bedeutet, dass die Mannschaft aktiv nach vorne spielt, Chancen kreiert und den Gegner unter Druck setzt („Pressing“). Ein Nebenaspekt, der auch in der IT wesentlich ist: Alle haben mehr Freude an der Arbeit.
Taktik 1: Teamwork und Zusammenarbeit
Ein zentraler Enabler für die Umsetzung der Offensivstrategie war die Förderung des Teamgeistes. Es gelang ihm, jeden seiner Superstars zu überzeugen, dass nur der gemeinsame Erfolg zählt und nicht die individuelle Leistung. Jeder Spieler muss sich in den Dienst des Teams stellen. Starallüren und Alleingänge sind verpönt.
Taktik 2: Flexibilität und Anpassungsfähigkeit
Im Fußball unterscheidet man die Prinzipien „Raumdeckung“ und „Manndeckung“. Immer noch wird bei der Mannschaftsaufstellung jedem Spieler eine bestimmte Position am Spielfeld zugeteilt. Wenn von den Spielern erwartet wird, dass sie möglichst am zugeteilten Ort bleiben und gegnerische Spieler attackieren, die dort eindringen, ist das „Raumdeckung“. Wenn man hingegen den Verteidigern einen gegnerischen Spieler zuteilt, den sie unabhängig von der zugeteilten Position an der Ballannahme und insbesondere an Torschüssen hindern sollen, ist es das Prinzip der Manndeckung. Übrigens wird dieser Begriff auch im Frauenfußball (noch?) verwendet.
Luis de la Fuente praktiziert ein hybrides Konzept, die Spieler müssen je nach Situation entscheiden, welches Prinzip sie priorisieren. Das erfordert hohe Flexibilität und vor allem auch eine hervorragende Kommunikation im Team. Missverständnisse können dazu führen, dass plötzlich ein gegnerischer Spieler allein vor dem Tor steht. Defensive Mannschaften orientieren sich stärker am Prinzip Raumdeckung, sie „mauern“.
Taktik 3: Förderung von Kreativität
Obwohl es detaillierte Vorgaben auf Grundlage der Analyse der gegnerischen Mannschaft gibt, wird von jedem Spieler erwartet, dass er den Mut hat, von einer Vorgabe abzuweichen, wenn dies mehr Erfolg verspricht. Das erfordert Mut und auch eine positive Fehlerkultur, denn die Verantwortung für Fehler kann nicht auf eine höhere Instanz abgeschoben werden.
Erfolgsfaktor „Execution“
Die Umstellung der Spielanlage der Nationalmannschaft verlief nicht ohne Rückschläge. Die Niederlage gegen Schottland in der EM-Qualifikation im März 2023 und die Schwierigkeiten in Spielen der UEFA Nations League 2022 gegen Schottland, Tschechien und die Schweiz sind konkrete Beispiele für Rückschläge, die Luis de la Fuente in der Anfangsphase seiner Amtszeit erlebte. Er ließ sich davon nicht beirren, sondern arbeitete weiterhin an der konsequenten Umsetzung seiner Strategie. Als Erfolgskriterium definierte er den Gewinn der Europameisterschaft. Der zwischenzeitliche Sieg in der Nations League 2023 war natürlich hilfreich. Da hatte er allerdings auch Glück, denn der Sieg im Elfmeterschießen im Finale gegen Kroatien war denkbar knapp. Man kann davon ausgehen, dass er auch im Falle einer Niederlage in der Nations League seine Strategie beibehalten hätte.
An dieser Stelle muss ich klären, wer in meinen Analogien die Rolle der gegnerischen Mannschaft wahrnimmt. Es sind nicht die Kunden der IT-Abteilung (auch wenn es sich manchmal so anfühlt)! Ich meine damit die faktischen Herausforderungen der Aufgabenstellung, die letztlich nur Anwender (Fachabteilungen, Kunden) gemeinsam mit der IT-Abteilung (interne IT-Abteilung und/oder externes IT-Unternehmen) bewältigen können.
1. Offensiv statt defensiv und Pressing
In IT-Abteilungen dominiert nach meiner Erfahrung eine geradezu reflexartige Abwehr gegenüber neuen Anforderungen. Natürlich wissen wir alle, dass es dafür gute Gründe gibt: begrenzte Kapazitäten, unklare und oft unreflektierte IT-Anforderungen, hohe Wartungs- und Anpassungsaufwände für in die Jahre gekommene Alt-Systeme etc. Und natürlich ist der effektivste Weg, Kapazität zu gewinnen, Projekte gar nicht erst zu beginnen.
Ein Prinzip des agilen Manifests geht genau in diese Richtung: „Die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essenziell“. Dieses Zitat habe ich allerdings verfälscht, denn vollständig lautet das Prinzip so: „Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell“. Einfache Lösungen erzielt man allerdings nur, wenn man sich mit einer Anforderung eingehend beschäftigt hat.
Wenn ich für „Pressing“ plädiere, meine ich damit die möglichst frühe intensive Auseinandersetzung mit Anforderungen, die Suche nach Lösungsmöglichkeiten, die Suche nach möglichst einfachen Lösungen durch Prozessinnovation und durch IT-Funktionen. Das kann nicht mit einem generalisierten Abwehrreflex gelingen. Auch wenn nach eingehender gemeinsamer Analyse am Ende eine Anforderung nicht umgesetzt werden kann, wird die Akzeptanz auf Kundenseite deutlich höher sein als wenn von Anfang an hinhaltender Widerstand geleistet wurde. Und wenn der hinhaltende Widerstand der IT-Abteilung durch ein Machtwort des Managements gebrochen wird, ist die Freude darüber auf Kundenseite getrübt und die IT-Abteilung ist ohnehin frustriert.
Eine besonders unangenehme Form des hinhaltenden Widerstandes ist der Verweis, dass es sich hier um eine neue Anforderung handle, die so im urspünglichen Auftrag nicht enthalten war. Im agilen Manifest heißt es dazu: „Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“ Ich muss zugeben, dass ich diesen Zugang auch in agilen Projekten noch nie erlebt habe. Das kann an der Einseitigkeit meiner Projekterfahrungen liegen, aber nach über 30 Jahren in diesem Feld fürchte ich, dass es nicht nur an mir liegt.
Heißt das, man sollte Anforderungen immer umsetzen? Natürlich nicht! Jede Anforderung ist allerdings danach zu beurteilen, ob sie einen Wertbeitrag leistet. Man kann bei einer immer schon formulierten Anforderung später erkennen, dass es nicht sinnvoll ist, sie umzusetzen. Und es kann bei einer völlig neuen Anforderungen in späten Phasen eines Projektes so sein, dass es für den Erfolg des Projektes wesentlich ist, ob diese Anforderung umgesetzt wird oder nicht. Ich plädiere hier also für einen Zugang, der dem „Zero Base Budgeting“ gleicht: Dass etwas immer schon so gewesen ist, kann die Entscheidung von heute nicht determinieren. Die Entscheidung orientiert sich immer am Beitrag zur Erreichung des Ziels.
Die Umstellung der Strategie erfordert Aufwand und dafür geeignete und motivierte Mitarbeiter*innen. Aber diese Belastungsspitze (den bekannten Hockeyschläger-Effekt) kann man durch Zukauf von externen Ressourcen bewältigen. Ja, dafür sind Berater da! Sie müssen allerdings daran arbeiten, Know-How-Transfer zu betreiben und an ihrer eigenen Entbehrlichkeit zu arbeiten. Das erfordert eine konsequente Steuerung auf Seiten der Auftraggeber, es ist kein Selbstläufer. Aber wo gibt es schon Selbstläufer?
2. Teamwork und Zusammenarbeit
Dass IT-Projekte nicht gelingen, wenn das Team in sich zerstritten ist, muss man nicht weiter erläutern. Dass sie aber auch nicht gelingen können, wenn Anwender/Kunden und die IT-Abteilung einander misstrauen, Finger-Pointing betreiben anstatt zusammen zu arbeiten, weiß zwar auch jeder, die Praxis sieht allerdings oft anders aus. Ich habe in meinem Berufsleben das Thema Teambuilding immer hoch gewichtet. Immerhin habe ich Psychologie studiert und habe zahlreiche Berufsjahre als Führungskräftetrainer gearbeitet und selbst Führungsfunktionen in Beratungsunternehmen innegehabt. Ich werde auf das Thema Team Building in einem späteren Blogbeitrag eingehen.
3. Flexibilität und Anpassungsfähigkeit
Agile Ansätze sind ja eigentlich der Inbegriff von Flexibilität. Wenn ich mir allerdings die Anwendung agiler Frameworks in der Praxis ansehe, vermisse ich diese Eigenschaften sehr oft. Das sind einige der typischen Symptome:
Ich habe dazu schon in einem früheren Newsletter ausführlich Stellung genommen, daher hier nur ein Link.
4. Förderung von Kreativität
Der Weg von einer fachlichen Anforderung zu einer IT-Lösung ist ein kreativer Prozess. Kreativität kann nur in einer kooperativen und konstruktiven Atmosphäre entstehen. Denken wir an Brainstorming als anerkannte Methode zur Erarbeitung kreativer Lösungen. Hier werden zunächst Ideen gesammelt, Bewertung und Kritik sind in dieser Phase strikt verboten. Wenn die IT-Abteilung unter dem Titel „Priorisierung“ damit beginnt, die Berechtigung und Relevanz von Anforderungen in Frage zu stellen, bevor man noch nach einer möglichen Lösung gesucht hat, entsteht sicher kein kreativer Prozess. Der kreative Prozess kann aber dazu führen, eine ursprünglich als wichtig klassifizierte Anforderung zu verwerfen, weil eine bessere Alternative gefunden wurde. Das ist ein Vorteil für alle, vor allem für das Unternehmen insgesamt.
Die Arbeit an IT-Lösungen kann nur in Form einer Zusammenarbeit auf Augenhöhe, mit gegenseitigem Respekt und einem ergebnisoffenen Ansatz erfolgreich verlaufen. Dabei müssen auch die Anwender bereit sein, das Hinterfragen ihrer Anforderungen durch die IT zu akzeptieren. Die lnformationstechnologie weist eine extreme Änderungsdynamik auf und schafft so immer neue Möglichkeiten der Prozessgestaltung. Meist entstehen Anforderungen auf Basis bekannter Architekturen und Technologien. Das Potenzial von am Markt verfügbaren Technologien muss in den Anforderungsprozess von der IT-Abteilung eingebracht werden und dabei können Lösungen entstehen, die kostengünstiger und effizienter sind als jene, die Grundlage der ursprünglichen Anforderung waren.
Erfolgsfaktor Execution
Die erfolgreiche Umsetzung einer Offensivstrategie als leitendes Prinzip der IT Governance erfordert auch die richtigen Personen im Management. Wenn hier so stark auf Luis de la Fuente abgestellt wurde, so vereinfacht das die Geschichte des Erfolges. Er war offenbar jene Person, die den Anstoß gegeben und die Umsetzung konsequent vorangetrieben hat. Aber insgesamt braucht man für den Erfolg eine große Zahl von Personen, die in ihrer Rolle zum Erfolg beitragen müssen.
Stellt man die Strategie um, so sind Rückschläge unvermeidlich, der Hockeyschläger-Effekt gilt auch für die Erfolgskurve, es wird zunächst vieles schlechter funktionieren. Ohne den Mut, einen Change-Prozess durchzuziehen, auch wenn es zwischendurch Schwierigkeiten gibt, kann es (leider) nicht funktionieren.
Mit diesem Beitrag appeliere ich an alle, die für die IT Governance in Unternehmen und im öffentlichen Sektor verantwortlich sind, sich vom Erfolg von Luis de la Fuente ermutigen zu lassen und auf eine offensive Strategie umzustellen. Es ist schwierig, aber es lohnt sich!
