Priorisierung – ein Sammelplatz für Scheinklarheiten!

Stellen Sie sich gefälligst hinten an!

Wer den Song der Ersten Allgemeinen Verunsicherung über einen misslungenen Banküberfall kennt, kann die Formulierung einordnen. Die energische Dame bringt damit den Bankräuber aus dem Konzept.

Die Regel, dass man sich bei einer Warteschlange nicht vordrängen darf, gilt für zahlreiche Alltagssituationen. Sie klingt einfach, ist es aber nicht. Sie wird auch oft missachtet, nicht nur von Bankräubern.

Im Supermarkt wird manchmal eine zusätzliche Kassa eröffnet und dann stellt sich die Frage, ob ich zu dieser wechseln soll und ob es OK ist, dass ich damit andere überhole. Lasse ich Leute vor, die nur sehr wenige Artikel haben und was ist, wenn gleich zwei solche hinter mir stehen? Im Autoverkehr gilt das Reißverschlussprinzip als Empfehlung beim Zusammenführen von zwei Kolonnen, ist aber keine verbindliche Regel.

Bei diesen Entscheidungen mischen sich Fragen der Effizienz mit solchen der Moral oder zumindest des guten Benehmens. Aber selbst die Effizienfrage ist nicht klar zu beantworten. Zählt die Effizienz des Gesamtsystems (durchschnittliche Wartezeit aller Kunden und Umsatz je Kassa) oder die einer einzelnen Person (meine persönliche Wartezeit)? Was ist gerecht oder aus anderen Gründen moralisch geboten (etwa beim Zahnarzt Personen mit akuten Schmerzen vorzulassen und dafür selbst eine längere Wartezeit in Kauf zu nehmen)?

Ich breche hier ab, denn es ist ein unendliches Thema mit hoher Emotionalität. Ich wollte damit nur demonstrieren, dass der Umgang mit Warteschlangen bei weitem nicht nur ein mathematisch komplexes Feld ist, wie es etwa der Wikipedia-Eintrag zur Warteschlangentheorievermuten ließe.

Agil = Backlog? Oder doch nicht?

Agile Vorgehensmodelle haben die Frage der Reihung von Anforderungen in einer Weise sichtbar gemacht, wie es in klassischen Vorgehensmodellen nicht der Fall war. Ein Lasten- oder Pflichtenheft beinhaltet eine vollständige Beschreibung der Anforderungen, jedenfalls ist das der Anspruch. Dort gibt es natürlich auch Aussagen zur Wichtigkeit und Dringlichkeit von Anforderungen, meist in Form einer Zuordnung zu Meilensteinen oder Phasen der gewünschten Umsetzung.

Scrum hat mit dem Konzept des Backlogs als einer geordneten Reihe von einzelnen Anforderungen (Backlog-Items, meist immer noch als User-Stories bezeichnet) ein Modell des Umgangs mit Anforderungen geschaffen, das vielfach mit agilem Vorgehen gleichgesetzt wird. Dabei wird übersehen, dass andere agile Ansätze kein so striktes Warteschlangen-Konzept kennen. Natürlich verlangen auch XP oder Lean von den „Kunden“ Aussagen über Wichtigkeit und Dringlichkeit von Anforderungen, aber es wird nicht erwartet, dass diese vom Kunden gereiht werden. Bei XP ist das ausdrücklich Gegenstand eines ständigen Dialogs, Kanban optimiert den Durchsatz, nicht zuletzt durch Vermeiden von Überlastung des Systems (WIP-Limit: Work in Progress wird auf die verfügbare Kapazität abgestimmt).

Womit der Scrum-Guide zweifellos recht hat ist die Klarstellung, dass in einem Projekt Entscheidungen getroffen werden müssen, was in welcher Reihenfolge erledigt werden soll: es muss priorisiert werden. Das ins allgemeine Bewusstsein gehoben zu haben, ist ein Verdienst des Scrum-Frameworks. Die Lösung ist allerdings höchst unvollständig.

Was ist Priorisierung?

Priorisierung soll sicherstellen, dass Ressourcen wie Zeit, Geld oder Personal für diejenigen Aktivitäten eingesetzt werden, die den höchsten Beitrag zur Erreichung der gesetzten Ziele liefern.

Dabei werden meist zwei Aspekte unterschieden: Wichtigkeit und Dringlichkeit.

Als Standard für den Umgang mit diesen beiden Aspekten gilt die sogenannte Eisenhower-Matrix (benannt nach dem ehemaligen US-Präsidenten). Sie teilt Aufgaben in vier Kategorien auf, die grafisch als Quadranten dargestellt werden.

Die Mutter aller Priorisierungsregeln: Die Eisenhower-Matrix

So lauten die Empfehlungen zur Anwendung dieser Matrix:

Wichtig und dringend (Quadrant 1): Höchste Priorität. Diese Aufgaben sollten sofort erledigt werden, da sie einen direkten Einfluss auf die Erreichung der Ziele und den Umgang mit dringenden Problemen haben.

Wichtig, aber nicht dringend (Quadrant 2): Zweithöchste Priorität. Sie tragen zur Erreichung der langfristigen Ziele bei. Diese müssen besonders beachtet werden, weil sie leicht aufgrund von Belastungen durch operative Aufgaben (siehe nächste Kategorie) vernachlässigt werden.

Nicht wichtig, aber dringend (Quadrant 3): Diese sollten nach den wichtigen Aufgaben erledigt werden. Nach Möglichkeit sollten diese delegiert (bzw. outgesourct) werden.

Nicht wichtig und nicht dringend (Quadrant 4): Diese sollten möglichst eliminiert oder mit minimalem Aufwand erledigt werden.

Die Matrix, selbst schon eine starke Vereinfachung der realen Herausforderungen, ergibt allerdings keine eindimensionale Reihung, wie sie für einen Backlog gefordert wird.

So einfach und klar das Modell auch scheint, allein die Frage der Entscheidung, was wichtig oder nicht wichtig ist, ist alles andere als trivial. Gleiches gilt für die Dringlichkeit. Wer trifft diese Entscheidung? Nach welchen Kriterien werden Anforderungen als mehr oder weniger wichtig oder dringlich klassifiziert?

Scrum: Es darf nur einen geben!

Scrum macht es sich leicht. Wie die „Reihenfolge des Product Backlogs“ zustande kommt, ist eine Entscheidung des/der Product Owner:in, die von der gesamten Organisation zu respektieren ist, so der Scrum Guide 2020. Diese Allmacht des Product Owners klingt gut, in Wirklichkeit ist es aber eine Folge des Ursprungs von Scrum aus einer rein technischen Perspektive. Die Entwickler wollen die Entscheidung, in welcher Reihenfolge die Anforderungen zu erledigen sind, nicht in ihre Verantwortung übernehmen. Sie wollen wissen, was sie zu tun haben und dabei nicht gestört werden. Insofern propagiert Scrum – ich sage das immer wieder – ein Paradies für Entwickler und das erklärt die Beliebtheit dieses Frameworks in der technischen Community. Der Erfolg eines Projektes oder Programms hängt allerdings nur zu einem Teil von der Effizienz der Entwicklungsarbeit ab und insofern ist Scrum in einer gefährlichen Weise unvollständig. Dazu habe ich schon in einem früheren Blogbeitrag mehr gesagt.

Erste Komplikation: Das Ganze ist mehr als die Summe seiner Teile

Es ist eine gute Idee, große Aufgaben in kleine Einheiten herunterzubrechen und diese dann schrittweise abzuarbeiten. Wenn man allerdings zu früh mit der Zerlegung beginnt oder überhaupt nur mit der Sammlung von User-Stories beginnt, sieht man den Wald vor lauter Bäumen nicht mehr. Die Backlog-Items stehen in Wechselwirkung, sie gehören möglicherweise zu unterschiedlichen Teilsystemen. Ich habe immer wieder erlebt, dass sich agile Projekte mit Releaseterminen schwer tun, die völlig unabhängig von den konkreten Inhalten fixiert werden, weil das aus organisatorischen Gründen, wegen der erforderlichen Inormations- und Schulungsaufwände, der Aufwände für Fachtest und Abnahmen etc. nur so lösbar ist. Bei der Entscheidung, welche Backlog-Items im nächsten Sprint bearbeitet werden, kann nicht nur ihr Business-Nutzen isoliert betrachtet werden, auch weniger wertvolle Items müssen manchmal umgesetzt werden, weil sonst das Deployment eines Releases nicht funktionieren würde.

Hier muss man anerkennen, dass SAFe sich dieser Herausforderung stellt und systematisch abhandelt. Neben der Team-Ebene (in der Wahrnehmung von Agilität meist die einzige) kennt SAFe mehrere weitere Ebenen, die unterschiedliche Aspekte der Organisation und Koordination von großen Programmen und Portfolios abdecken. Hier sind die wichtigsten Ebenen im SAFe-Framework:

1. Team-Ebene:

Ziel: Hier arbeiten agile Teams (Scrum, Kanban oder XP) und liefern in kurzen Iterationen (Sprints) inkrementelle Wertschöpfung.

Elemente: Agile Teams, Iterationen, Scrum Master, Product Owner, Backlog, etc.

2. Programm-Ebene:

Ziel: Diese Ebene koordiniert mehrere agile Teams, die zusammenarbeiten, um ein gemeinsames Produkt oder System zu liefern.

Elemente:

Agile Release Train (ART): Ein Zug (Train) aus mehreren agilen Teams, die synchronisiert arbeiten, um regelmäßig wertvolle Inkremente zu liefern.

Program Increment (PI): Ein Zeitrahmen (typischerweise 8-12 Wochen), innerhalb dessen der ART inkrementelle Wertschöpfung liefert.

Release Train Engineer (RTE): Ein Coach und Manager des ART.

Program Backlog: Eine Sammlung von Features und Enablern, die für den ART priorisiert werden.

3. Solution-Ebene (optional):

Ziel: Diese Ebene wird verwendet, wenn ein Unternehmen sehr große, komplexe Lösungen entwickelt, die mehrere ARTs umfassen.

Elemente:

Solution Train: Koordiniert mehrere ARTs und Lieferanten, um eine umfassende Lösung zu entwickeln.

Solution Architect/Engineering: Verantworlich für die technische Vision und Architektur der Lösung.

Solution Management: Verantwortlich für die Priorisierung der Solution Backlog und die Wertmaximierung.

Solution Backlog: Eine Sammlung von Capabilities, die die großen Funktionsblöcke einer Lösung darstellen.

4. Portfolio-Ebene:

– Ziel: Diese Ebene steuert die gesamte Produktentwicklung und Ausrichtung der Geschäftsinvestitionen auf die strategischen Ziele der Organisation.

Elemente:

Lean Portfolio Management (LPM): Verwalten des Portfolios an Programmen und Budgets.

Epic Owners: Verantwortlich für die Steuerung von Epics (große Initiativen, die mehrere ARTs betreffen).

Portfolio Backlog: Eine Sammlung von Epics und anderen Initiativen, die die strategische Ausrichtung der Organisation unterstützen.

– Strategic Themes: Leitende Geschäftsziele, die die Prioritäten des Portfolios beeinflussen.

5. Enterprise-Ebene (oft „Large Solution“ genannt):

Ziel: Diese Ebene befasst sich mit der gesamten Organisation und deren strategischen Zielen. Sie sichert die Ausrichtung aller Ebenen auf die Unternehmensstrategie.

Elemente:

Enterprise Architect: Stellt sicher, dass die technische Architektur und die Entwicklungsausrichtung mit den Unternehmenszielen übereinstimmen.

Enterprise Portfolio: Ein übergeordnetes Portfolio, das alle wichtigen strategischen Initiativen des Unternehmens umfasst.

Es wird hier klar, dass jede Priorisierung auf einer Ebene Kriterien der übergeordneten Ebenen berücksichtigten muss. Das ohne inhaltliche Festlegungen der Willkür eines Product Owners (noch dazu mit der Auflage, dass es nur eine Person und kein Team sein darf) zu überlassen, wird den Herausforderungen großer Organisationen offenbar nicht gerecht. Dass SAFe auch dazu führen kann, viel Overhead aufzubauen, ist auch korrekt. Wir sind wieder bei der bekannten Forderung, das Vorgehen der konkreten Situation anzupassen. Dazu in einem früheren Blogbeitrag mehr.

Zweite Komplikation: Wir arbeiten auch für die Tribüne

Ich habe die Emotionalität beim Umgang mit Warteschlangen zu Beginn am Beispiel von Alltagssituationen erwähnt. Aber auch in einem professionellen Umfeld geht es nicht nur um die pure Ratio. Als Projektmanager habe ich mit Stakeholdern zu tun und diese haben Erwartungen, die man nicht mit Verweis auf die Ergebnisse einer mathematisch untermauerten Priorisierung ignorieren kann.

Um das Vertrauen in die Projektarbeit aufrecht zu erhalten oder wieder zu reparieren, muss man manchmal „etwas herzeigen“. Nicht immer ist das aus Sicht der Gesamteffizienz das wichtigste und dringendste Ergebnis, es muss „nur“ nachvollziehbar und überzeugend sein. Dafür muss man Aufgaben priorisieren, die in einer streng rationalen Betrachtung noch nicht auf der Agenda stehen.

Dritte Komplikation: Die Erfolgskriterien sind weder konsistent noch stabil

Es gibt keinen Ansatz im Projektmanagement, der die Pririsierung so hoch gewichtet wie CCPM (Critical Chain Project Management, basierend auf der Theory of Constraints). Wir lernen daraus, dass es geradezu naturgesetzliche Regeln gibt, Aufgaben zu priorisieren, wenn man ein definiertes Ziel erreichen will. CCPM geht davon aus, dass es darum geht, den Durchsatz eines Systems zu erhöhen. Tatsächlich ist die Menge an erledigter Arbeit der wichtigste Hebel, um ein Projekt zum Erfolg zu führen.

Auch wenn dank der ausgefeilten Methodik von CCPM „Doing the things right“ optimal funktioniert, bleibt die Herausforderung von „Doing the right things“ auf strategischer Ebene bestehen. Ich gehöre selbst dem Netzwerk „Dolphin Universe“ an, weil ich dieses Know-How unglaublich wertvoll finde. Aber ich muss darauf hinweisen, dass im magischen Dreieck von Ergebnis, Termin und Aufwand die Gewichtung in jedem Projekt unterschiedlich ist und sich auch im Verlauf eines Projektes ändert. „Whatever it takes“ gilt manchmal auch in Projekten, in anderen ist wiederum das Budget ein limitierender Faktor. Und zudem sind die offiziellen Aussage nicht immer identisch mit den tatsächlichen Kriterien. Ein rational zweifellos allen Ansätzen überlegenes Verfahren wie CCPM kann in einer Welt voller Irrationalität keine umfassende Orientierung bieten.

Wie man die Prioritäten in einer konkreten Situation bestimmen soll, hängt also von Kriterien ab, die nicht immer klar und oft auch widersprüchlich sind.

Hier bietet wiederum SAFe einen interessanten Ansatz, weil die Funktion des Product Owners durch die des Product Managers ergänzt wird und zwischen einer strategischen und einer operativen Betrachtung unterschieden wird.

Product Manager:

Strategisches Niveau: Der Product Manager ist hauptsächlich für die strategische Ausrichtung des Produkts verantwortlich. Dies umfasst die Entwicklung der Produktvision, die Erstellung der Produkt-Roadmap und die Priorisierung von Features und Epics auf höherer Ebene.

Marktorientierung: Der Product Manager agiert auf einer übergeordneten Ebene und arbeitet eng mit Kunden, Marktanalysten und anderen Stakeholdern zusammen, um sicherzustellen, dass das Produkt die Marktanforderungen erfüllt und strategische Geschäftsziele unterstützt.

Program Backlog: Der Product Manager verwaltet das Program Backlog und priorisiert Features, die in den Agile Release Trains (ARTs) umgesetzt werden sollen.

Product Owner:

Operatives Niveau: Der Product Owner ist auf operativer Ebene tätig und verantwortlich für die Umsetzung der Vision und Strategie des Product Managers in konkrete Arbeitspakete (User Stories).

Teamorientierung: Der Product Owner arbeitet eng mit den Entwicklungsteams zusammen, um sicherzustellen, dass die Anforderungen klar definiert sind und die Teams die richtigen Aufgaben priorisieren und umsetzen.

Team Backlog: Der Product Owner verwaltet das Team Backlog und ist dafür verantwortlich, User Stories zu priorisieren und detaillierte Anforderungen zu spezifizieren, die während der Iterationen bearbeitet werden.

Man muss sich nicht den ganzen Overhead von SAFe einhandeln, um die Abwägung von strategischen und operativen Priorisierungen umzusetzen.

Vierte Komplikation: Wir wissen nicht alles und haben keine Zeit, unseren Informationsstand zu perfektionieren

Schon in Zusammenhang mit der Eisenhower-Matrix habe ich angemerkt, dass es in der Praxis nicht so einfach festzustellen ist, was wichtig und was dringend ist. Das gilt schon für die Selbstoptimierung, erst recht gilt es für komplexe Systeme wie z.B. Unternehmen, Programme und Projekte.

Erfreulicherweise ist das nicht unbedingt ein Nachteil. Bernd Gigerenzer und sein Forschungsteam haben zeigen können, dass relativ simple Heuristiken oft mehr Erfolg bringen als aufwändige Verfahren zur Entscheidungsfindung. Ich habe das in einem Blogbeitrag beschrieben.

Für alle, die lieber einem erfolgreichen Manager vertrauen als der Wissenschaft (hier sind wohl nur Leute, die beides tun), hier noch ein Beitrag von Gerhard Zeiler, dem international erfolgreichen Medienmanager.

Wir müssen einfach akzeptieren, dass jede Priorisierungsentscheidung die wir treffen besser ist als keine Entscheidung. Just do it! Das ruft mir das Logo meiner Laufschuhe zu und es ist ein guter Rat, nicht perfekt, aber hlfreich!

Anforderungsanalyse und Design trennen? – IT-Governance Blog

„Bitte lasst uns in Ruhe arbeiten“, „Bitte mischt euch nicht in die technischen Fragen ein“ sagen oft Entwickler*innen. „Zu technischen Fragen kann ich nichts sagen“, „Bitte klärt die technischen Fragen ohne mich“ sagen oft Anwender*innen.

„Die IT soll machen, was man ihr sagt“, so der O-Ton schon in mehreren Projekten, an denen ich in verschiedenen Rollen beteiligt war. „Die IT ist ein Dienstleister“ ist nicht zufällig eines der 12 Kapitel meines Buches „12 Halbwahrheiten über IT-Projekte„.

Im Grunde genommen sind solche Statements eine Manifestation des Wasserfallmodells, das auch in offiziell agilen Projekten immer noch das Denken vieler Stakeholder bestimmt. Aus dem großen Wasserfall werden viele kleine Wasserfälle, es ist nur deren Scope reduziert worden auf Sprints oder oft sogar auf User-Stories. Das ist kein wirklicher Fortschritt und die Ergebnisse sind dementsprechend bescheiden.

User-Stories beseitigen Barrieren, fördern aber Oberflächlichkeit

An sich ist das Konzept der User-Stories positiv zu werten. Ich habe schon erlebt, dass Entwicklerteams dafür eintraten, die Anwender*innen mögen doch UML oder BPMN lernen und damit die Anforderungen gleich in einem Format liefern, dass direkt umsetzbar ist. Im Vergleich dazu sind User-Stores ein Schritt in die gegenteilige Richtung. Die Anforderungen werden weitgehend entformalisiert. User-Stories sind daher ein guter Start in den Prozess der Anforderungsanalyse, aber sie dürfen nicht deren Endpunkt sein. Es ist bedauerlich, dass vor allem unter dem Einfluss von Scrum die existierende Vielfalt an möglichen Formen der Anforderungsdefinition in der Praxis verloren gegangen ist.

IREB etwa nennt eine bemerkenswerte Vielfalt an Formaten zur Definition von Anforderungen, darunter auch die in agilen Teams meist als veraltet angesehenen Lasten- und Pflichtenhefte:

User Stories:

  • Beschreibung: User Stories sind kurze, einfache Beschreibungen einer Funktion oder eines Features aus der Sicht eines Endnutzers oder Stakeholders. Sie folgen oft der Struktur: „Als [Nutzerrolle] möchte ich [Ziel/Wunsch], um [Nutzen].“

  • Verwendung: User Stories werden häufig in agilen Projekten verwendet und dienen als Grundlage für die Planung und Priorisierung von Entwicklungsaufgaben. Sie sind in der Regel bewusst kurz gehalten und werden während der Entwicklung weiter verfeinert.

Epics:

  • Beschreibung: Epics sind große, grobgranulare Anforderungen oder Funktionen, die oft in mehrere User Stories unterteilt werden können. Sie dienen als eine Art Sammelpunkt für umfangreiche Features oder größere Geschäftsziele, die über einen längeren Zeitraum hinweg entwickelt werden.

  • Verwendung: Epics werden genutzt, um eine übergeordnete Vision oder ein Ziel zu beschreiben, das später in kleinere, handhabbare Teile (User Stories) zerlegt wird. Sie bieten einen Überblick und helfen dabei, den Kontext für die nachfolgenden User Stories zu schaffen.

Anwendungsfälle (Use Cases):

  • Beschreibung: Anwendungsfälle beschreiben detailliert, wie ein Nutzer (Akteur) mit einem System interagiert, um ein bestimmtes Ziel zu erreichen. Sie umfassen sowohl den normalen Ablauf als auch alternative Szenarien und Fehlerszenarien.

  • Verwendung: Use Cases werden eingesetzt, um komplexe Interaktionen zwischen Nutzern und Systemen präzise zu erfassen und dienen als Grundlage für die Systemmodellierung und Testfallentwicklung.

Szenarien:

  • Beschreibung: Szenarien sind narrative Beschreibungen konkreter Nutzungssituationen. Sie skizzieren mehr oder minder formalisiert typische Abläufe und zeigen, wie das System in bestimmten Situationen genutzt wird.

  • Verwendung: Szenarien eignen sich besonders gut, um Anforderungen verständlich zu machen und die User Experience zu erfassen. Sie unterstützen das Verständnis komplexer Anforderungen und deren Auswirkungen.

Lastenheft:

  • Beschreibung: Ein Lastenheft dokumentiert alle Anforderungen aus Sicht des Auftraggebers. Es beschreibt, was das zu entwickelnde System leisten soll, ohne dabei eine Lösung vorzugeben.

  • Verwendung: Das Lastenheft dient als Ausgangspunkt für die Erstellung des Pflichtenhefts und ist ein zentrales Dokument in der Vertragsgestaltung zwischen Auftraggeber und Auftragnehmer.

Pflichtenheft:

  • Beschreibung: Im Pflichtenheft werden die Anforderungen des Lastenhefts detailliert spezifiziert und konkretisiert, um die technische Umsetzung zu beschreiben. Es enthält Lösungsvorschläge, technische Spezifikationen und beschreibt, wie die Anforderungen erfüllt werden sollen.

  • Verwendung: Das Pflichtenheft dient der Abstimmung zwischen den technischen Teams und dem Auftraggeber und bildet die Grundlage für die Systementwicklung und das Projektmanagement.

Prototypen:

  • Beschreibung: Prototypen sind frühe, oft vereinfachte Versionen eines Systems oder von Teilen eines Systems. Zur Klärung des User-Interface werden oft Wireframes verwendet.

  • Verwendung: Prototypen werden genutzt, um Anforderungen zu validieren und Missverständnisse frühzeitig zu klären. Sie sind besonders hilfreich, um Feedback von Stakeholdern zu sammeln und die Anforderungen iterativ zu verfeinern.

Zustandsdiagramme:

  • Beschreibung: Zustandsdiagramme visualisieren die Zustände eines Systems und die Übergänge zwischen diesen Zuständen in Reaktion auf Ereignisse.

  • Verwendung: Sie werden verwendet, um die dynamischen Aspekte eines Systems zu modellieren, insbesondere in Systemen, bei denen Zustandsänderungen eine wichtige Rolle spielen.

Mir sind alle Formen der Informationsübermittlung willkommen, in einem ersten Schritt sollte man diese in der Art akzeptieren, die der Denkweise und Terminologie der betreffenden Stakeholder am nächsten ist, andernfalls man gleich einen problematischen Filter einbaut. Oft habe ich erlebt, dass etwas als neue Anforderung gewertet wurde, was einfach vorher nicht zur Sprache kam, weil ein bestimmtes Format der Anforderungsdefinition vorgegeben war. Und ganz allgemein hat der alte Satz „Ein Bild sagt mehr als tausend Worte“ auch in Bezug auf User-Stories Gültigkeit. Manche Informationen lassen sich nur mit Bildern und relativ komplexer Prosa nachvollziehbar beschreiben.

Dass Story-Points eine nützliche Annäherung an die Ermittlung des Aufwandes sind, bleibt unbestritten. Aber auch hier gilt, dass es nur ein Einstieg sein kann und man dabei nicht stehen bleiben darf.

Die Anforderungen müssen als verschiedenen Perspektiven betrachtet werden

Laut den UML-Standards müssen bei der Modellierung von Anforderungen fünf verschiedene Perspektiven berücksichtigt werden:

1. Anwender-Perspektive (User’s Perspective):

– Fokussiert auf die Bedürfnisse und Ziele der Endnutzer des Systems.

– Beschreibt die Funktionalitäten, die der Anwender vom System erwartet.

2. Geschäfts-Perspektive (Business Perspective):

– Betrachtet die Anforderungen aus Sicht der Geschäftsprozesse und Strategien.

– Stellt sicher, dass das System die Geschäftsziele unterstützt.

3. Aufgaben-Perspektive (Task Perspective):

– Konzentriert sich auf die Abläufe und Aktivitäten, die das System unterstützen soll.

– Beschreibt, wie Benutzer mit dem System interagieren.

4. Implementierungs-Perspektive (Implementation Perspective):

– Betrachtet die technischen Anforderungen und Randbedingungen der Systemarchitektur.

– Stellt sicher, dass die Anforderungen technisch umsetzbar sind.

5. Umgebungs-Perspektive (Environment Perspective):

– Berücksichtigt externe Faktoren wie Gesetze, Regulierungen, Branchenstandards usw.

– Stellt sicher, dass das System mit den relevanten Rahmenbedingungen konform ist.

User-Stories adressieren die Anwender-Perspektive und wie schon gesagt, ist es sehr begrüßenswert, dass die formalen Einstiegshürden für die Formulierung von Anforderungen dadurch niedrig gehalten werden. Aber wie sollen aus einer User-Story die anderen Perspektiven abgeleitet werden, ohne wesentlich aufwändigere Darstellungsformen (siehe IREB oben) zu nutzen?

Die INVEST-Kriterien kritisch beleuchtet

Ein weit verbreitetes Konzept zur Bewertung von User-Stories (nicht zuletzt dank SAFe) sind die Kriterien, die mit dem Akronym INVEST zusammengefasst werden:

  1. Independent (Unabhängig): Eine User-Story sollte unabhängig von anderen Stories sein und für sich selbst stehen können. Dadurch wird die Priorisierung und Planung erleichtert.

  2. Negotiable (Verhandelbar): Die Details einer User-Story sollten noch nicht vollständig ausgearbeitet sein. Das ermöglicht es, gemeinsam mit dem Kunden die Anforderungen zu verfeinern und anzupassen.

  3. Valuable (Wertvoll): Eine User-Story sollte einen messbaren Mehrwert für den Kunden oder Endnutzer bieten. Sie sollte einen konkreten Nutzen erfüllen und nicht nur technische Umsetzung sein.

  4. Estimable (Schätzbar): Der Aufwand zur Umsetzung einer User-Story sollte grob geschätzt werden können. Dies erleichtert die Planung und Priorisierung im Rahmen des Projekts.

  5. Small (Klein): Eine User-Story sollte möglichst klein und in sich abgeschlossen sein. Große, komplexe Stories werden in mehrere kleinere Stories aufgeteilt. Kleine Stories sind leichter zu verstehen, zu schätzen und umzusetzen.

  6. Testable (Testbar): Eine User-Story sollte so definiert sein, dass ihre Umsetzung getestet werden kann. Das erleichtert die Überprüfung, ob die Story vollständig umgesetzt wurde.

Meiner Meinung nach sind die Kriterien 1 und 4 nur beurteilbar, wenn man schon einiges an Analyseaufwand investiert hat. Abhängigkeiten zwischen Anforderungen können aufgrund jeder der 5 UML-Perspektiven bestehen und sind daher auf Grundlage der Anwender-Perspektive allein nicht erkennbar. Und was die Schätzbarkeit anbelangt, so ist es mir immer schon und immer noch ein Rätsel, wie man den Aufwand auf Grundlage von Epics und User-Stories ermitteln kann. Der tatsächliche Aufwand für die Umsetzung von funktionalen Anforderungen (diese sind in User-Stories grob beschrieben) hängt von so vielen Faktoren ab, die zu einem großen Teil völlig unabhängig vom fachlichen Inhalt wirken. Hier eine Liste ohne Anspruch auf Vollständigkeit.

INVEST ist eine sinnvolle Kriterienliste, allerdings muss man sie als perspektivischen Arbeitsauftrag verstehen, nicht als Checkliste, die man nach Vorliegen von User-Stories oder anderen Anforderungsbeschreibungen abhaken kann.

Es geht nur interaktiv und iterativ

Ich möchte an dieser Stelle und abschließend Dean Leffingwell als Autoriät heranziehen, denn er hat die Antwort auf meine Eingangsfrage in seinem Standardwerk schon 2011 auf den Punkt gebracht. Ich übernehme es 1:1.

Dean Leffingwell: Agile Software Requirements. S. 385

Und damit sind wir wieder bei den Empfehlungen, die ich schon früher am Beispiel von Max Verstappen und Adrian Neweybeschrieben habe.

Ob du recht hast oder nicht, sagt dir gleich …

Nein, nicht das Licht, in unserem Fall sagt uns das der Test. Allerdings ist Falsch und Richtig in IT-Projekten nicht so einfach zu definieren wie in Michael Schanzes legendärer Show „1, 2 oder 3“, die allerdings nur jene kennen, die zwischen 1977 und 1985 Kinderfernsehen konsumiert haben.

Die klassische Sicht auf Tests im V-Modell

Test spielen in allen Vorgehensmodellen eine große Rolle. Bei einem Werkvertrag geht es darum, die bei Vertragsabschluss festgelegten Eigenschaften des Produktes auf ihre Übereinstimmung mit der Lieferung zu testen. Tests stehen also ganz am Ende und es handelt sich um einen Abnahmetest.

Dieses Modell kann auch heute noch bei Hardwarelieferungen und für klar spezifizierbare Softwareprodukte praktiziert werden, allerdings sind auch hier viele eventuelle Mängel dabei nicht erkennbar.

Einen Schritt weiter in Richtung Realismus geht das V-Modell, es sieht Validierungen in allen Entwurfsphasen vor (siehe nachfolgende Grafik, über den Link gibt es auch ein informatives Video). Während der Implementierung finden natürlich auch Tests statt, diese sind allerdings in der Hoheit des Entwicklungsteams und setzen klar definierte und stabile Anforderungen voraus. Die Anforderungen der Anwender:innen und das Ergebnis der technsichen Umsetzung treffen erst beim Abnahmetest wieder aufeinander; jedenfalls wenn es laut Lehrbuch läuft.

Das V-Modell (Quelle: Studyflix)

Testen als durchgängiger Prozess – Die Sicht des SWEBOK

Der SWEBOK (Software Engineering Body of Knowledge) definiert Software-Testing als einen systematischen Prozess zur Bewertung der Qualität eines Softwareprodukts und zur Verbesserung dieser Qualität, indem Fehler erkannt und behoben werden. Testen ist dabei ein wichtiger Teil des Softwareentwicklungsprozesses, der sicherstellen soll, dass das Softwareprodukt die definierten Anforderungen erfüllt und korrekt funktioniert.

Im Detail beschreibt der SWEBOK das Testen wie folgt:

1. Ziel des Testens

– Das Hauptziel des Software-Tests ist es, Fehler und Abweichungen von den Anforderungen zu finden, um die Softwarequalität zu verbessern.

– Ein weiteres Ziel ist es, Vertrauen in die Software aufzubauen, indem gezeigt wird, dass sie unter den erwarteten Bedingungen korrekt funktioniert.

2. Testaktivitäten

SWEBOK unterteilt das Testen in verschiedene Phasen und Aktivitäten, die im Softwareentwicklungsprozess durchlaufen werden:

– Testplanung: Festlegung der Teststrategie, Testziele, Testarten, Zeitpläne und Ressourcen.

– Testdesign: Erstellung von Testfällen und Testdaten auf Basis der Spezifikationen und Anforderungen.

– Testimplementierung: Bereitstellung der Testumgebung und Einrichtung der Testwerkzeuge.

– Testdurchführung: Ausführung der Testfälle, Erfassung der Ergebnisse und Protokollierung von Abweichungen oder Fehlern.

– Testauswertung: Analyse der Testergebnisse, Bewertung der Softwarequalität und Entscheidung über die Freigabe der Software.

– Testdokumentation: Erstellung von Testberichten und Dokumentation der Testergebnisse.

3. Testebenen

Der SWEBOK beschreibt verschiedene Testebenen, darunter:

– Modultests (Unit Tests): Testen einzelner Softwarekomponenten oder Module.

– Integrationstests: Testen der Schnittstellen und Interaktionen zwischen verschiedenen Modulen, insbesondere auch solchen, die nicht Gegenstand der Entwicklungsarbeiten sind.

– Systemtests: Testen des gesamten Systems, um zu prüfen, ob es die definierten Anforderungen erfüllt.

– Abnahmetests (Acceptance Tests): Testen des Systems aus Sicht des Endbenutzers, um sicherzustellen, dass es den Geschäftszielen entspricht.

. Testmethoden

Der SWEBOK unterscheidet zwischen verschiedenen Testmethoden:

– White-Box-Testen: Der Tester kennt die interne Struktur der Software und testet spezifische Pfade und Anweisungen.

– Black-Box-Testen: Der Tester kennt die interne Implementierung nicht und testet die Funktionalität basierend auf den Anforderungen.

– Grey-Box-Testen: Eine Kombination aus White-Box- und Black-Box-Testen, bei der sowohl die Implementierung als auch die Spezifikationen berücksichtigt werden.

5. Testarten

Der SWEBOK erwähnt auch verschiedene Testarten:

– Funktionale Tests: Überprüfung, ob die Software die funktionalen Anforderungen erfüllt.

– Nicht-funktionale Tests: Testen von Aspekten wie Leistung, Sicherheit, Benutzerfreundlichkeit und Zuverlässigkeit.

– Regressionstests: Sicherstellen, dass Änderungen im Code keine neuen Fehler einführen.

– Explorative Tests: Tests ohne vorab definierte Testfälle, die der Erkundung des Systems und der Entdeckung von blinden Flecken in der Teststrategie dienen.

Der SWEBOK, den ich für einen viel zu wenig genutzten Schatz an Wissen halte, definiert Testen als einen umfassenden und strukturierten Prozess, der in jede Phase des Softwareentwicklungslebenszyklus integriert ist.

Testen als Teilbereich des Projektmanagements

Der SWEBOK deckt die Produkterstellungsprozesse ab, hinsichtlich der Prozesse des Projektmanagements verweist er auf die Standards des Project Management Institute (PMI). PMI sieht Tests als integralen Bestandteil des Projektmanagements, um die Qualität und Funktionalität der Projektergebnisse sicherzustellen. Hier sind einige wesentliche Punkte, die in den PMI-Standards zum Testen in IT-Projekten hervorgehoben werden:

  • Planung der Testaktivitäten: Tests sollten frühzeitig im Projektlebenszyklus geplant werden. Dies umfasst die Definition von Testzielen, Teststrategien und Testplänen, die sicherstellen, dass alle Anforderungen und Spezifikationen abgedeckt werden.
  • Testarten und -ebenen: PMI-Standards empfehlen die Durchführung verschiedener Testarten (z.B. Unit-Tests, Integrationstests, Systemtests, Abnahmetests) und Testebenen, um sicherzustellen, dass alle Aspekte der IT-Lösung gründlich geprüft werden.
  • Risikobasierte Tests: Die Priorisierung von Tests basierend auf dem Risiko hilft, die kritischsten Teile des Systems zuerst zu testen und sicherzustellen, dass die wichtigsten Funktionen und Sicherheitsanforderungen erfüllt werden.
  • Automatisierung von Tests: Die Automatisierung von Tests wird als Best Practice angesehen, um die Effizienz und Wiederholbarkeit der Tests zu erhöhen. Automatisierte Tests können helfen, Regressionen schnell zu identifizieren und die Qualität des Produkts kontinuierlich zu überwachen.
  • Dokumentation und Nachverfolgbarkeit: Eine gründliche Dokumentation der Testergebnisse und die Nachverfolgbarkeit von Fehlern und Korrekturen sind entscheidend, um sicherzustellen, dass alle Probleme identifiziert und behoben werden.
  • Kontinuierliche Verbesserung: PMI-Standards betonen die Bedeutung der kontinuierlichen Verbesserung der Testprozesse durch regelmäßige Überprüfungen und Anpassungen basierend auf den gesammelten Erfahrungen und Ergebnissen.

Diese Zusammenfassung aus einer größeren Zahl von Quellen habe ich mir übrigens von PMI’s Infinitymachen lassen, dem ChatBot, der auf qualitätsgesicherten Texten von PMI aufsetzt.

Testen in agilen Projekten

Die Teststrategie in agilen Projekten unterscheidet sich erheblich von der in klassischen Vorgehensmodellen. Agile Methoden wie Scrum oder Kanban legen großen Wert auf Flexibilität, kontinuierliche Verbesserung und enge Zusammenarbeit, was sich auch auf die Teststrategie auswirkt. Hier sind einige wesentliche Unterschiede:

  • Integrierte Tests: In agilen Projekten sind Tests ein integraler Bestandteil jedes Sprints oder Iteration. Tests werden kontinuierlich durchgeführt, anstatt am Ende des Projekts, wie es in klassischen Modellen oft der Fall ist.
  • Test-Driven Development (TDD): Agile Projekte nutzen häufig TDD, bei dem Tests vor der eigentlichen Implementierung geschrieben werden. Dies stellt sicher, dass der Code von Anfang an testbar ist und die Anforderungen erfüllt. TDD wird meist auf einer sehr technischen Ebene praktiziert, ich halte diesen Ansatz auch schon für frühe Phasen eines Projektes für praktikabel und wertvoll; dazu hier mehr.
  • Automatisierung: In agilen Projekten wird stark auf die Automatisierung von Tests gesetzt, um die Effizienz zu steigern und schnelle Feedback-Schleifen zu ermöglichen. Automatisierte Tests helfen, Regressionen schnell zu identifizieren und die Qualität des Produkts kontinuierlich zu überwachen.
  • Kontinuierliche Integration (CI): Agile Teams nutzen CI-Tools, um den Code regelmäßig zu integrieren und zu testen. Dies ermöglicht eine frühzeitige Erkennung von Fehlern und eine schnelle Behebung.
  • Kollaborative Ansätze: In agilen Projekten arbeiten Entwickler, Tester und andere Stakeholder eng zusammen. Diese Zusammenarbeit fördert ein gemeinsames Verständnis der Anforderungen und verbessert die Qualität der Tests.
  • Flexibilität und Anpassungsfähigkeit: Agile Teststrategien sind flexibel und passen sich den sich ändernden Anforderungen und Prioritäten an. Dies steht im Gegensatz zu den starren Testplänen in klassischen Modellen.
  • User Stories und Akzeptanzkriterien: Tests in agilen Projekten basieren oft auf User Stories und deren Akzeptanzkriterien. Ich habe an anderer Stelleschon darauf hingewiesen, dass dieser Detaillierungsgrad nicht ausreichend, als Minimalvorgabe und Einstieg aber nützlich und wertvoll ist.

Insgesamt wird klar, dass Testen in agilen Projekten in allen Phasen des Entwicklungsprozesses praktiziert wird. Noch wichtiger halte ich aber den grundsätzlichen Paradigmenwechsel. Testen vergleicht nicht vorab fixierte Anforderungen mit einem Ergebnis, dass bei Abweichungen zu korrigieren ist. Es stehen auch die Anforderungen zur Disposition, sie werden aufgrund von Testergebnissen detailliert und oft sogar modifiziert. Der Anteil an explorativen Tests steigt also signifikant. Sie sind nicht mehr, wie im SWEBOK vorgesehen, Ergänzungen der vordefinierten Testfälle, sie dienen auch der Präzisierung der Anforderungsdefinitionen und der Sicherung des Wertes der entwickelten Lösung

Testen ist ein zentales Steuerungsinstrument

Testen ist ein Messvorgang, der qualitative und quantitative Metriken auf die jeweiligen Arbeitsergebnisse anwendet. Aus der Physik lernen wir, dass der Messvorgang Teil jedes Messergebnisses ist. Es macht keinen Sinn, sich eine Realität (das Kant’sche „Ding an sich“ oder die „objektive Realität“) vorzustellen, die durch einen Messvorgang dann mehr oder minder korrekt abgebildet würde. Es gibt keine Realität unabhängig von unserer Beobachtung, die man im Sinne des Höhlengleichnisses mit unserer Wahrnehmung vergleichen könnte.

Der Projektfortschritt z.B. ist ein Konstrukt und je nach Definition wird im Projekt anders gearbeitet, Entscheidungen fallen anhand anderer oder zumindest anderer Gewichtungen der Entscheidungskriterien.  Durch die Messung wird also das System verändert, das man beobachtet. Die Teststrategie ist daher eine wesentliche Weichenstellung für den Verlauf eines Projektes. Was dort adressiert wird, erhält in der Projektarbeit höhere Priorität. Vor allem in den Schlussphasen eines Projektes werden die Testberichte zum wichtigsten Indikator für die Ermittlung des Effort to Complete und damit die Abschätzung des Go-Live-Termins und den Budget-Forecast.

Testen ist der ultimative Reality-Check. Es kann sehr schmerzhaft sein, wenn die vorher abgegebenen Einschätzungen des Fertigstellungsgrades am Ende schlagartig nach unten korrigiert werden müssen. In agilen Projekten ist diese Gefahr deutlich geringer als in Projekten nach einem klassischen Wasserfallmodell, aber es ist auch hier genug Raum für illusorische Fertigstellungsprognosen.

Alles muss getestet werden

Testpläne fokussieren meist auf die Prüfung der Software. Aber das greift zu kurz. Sehen wir Testen als universell gültiges Instrument des Vergleichs von Anspruch und Wirklichkeit, so müssen wir z.B. auch die Anforderungen testen. Sind diese geeignet, das eigentliche Projektziel, die Realisierung des Business Case zu realisieren? Sind die funktionalen und nicht-funktionalen Anforderungen vollständig und stimmen sie mit den tatsächlichen Herausforderungen des Projektes überein?

Jedes Zwischenergebnis in einem Projekt, ob es ein Projektplan, eine Schnittstellenfestlegung, eine Prozessdefinition oder was immer ist, kann gegen die Anforderung getestet werden, die durch dieses Ergebnis erfüllt werden soll.

Bei jeder Verfeinerung oder Konkretisierung einer Anforderung oder einer Lösungsbeschreibung muss geprüft werden, ob diese mit der abstrakteren Version noch übereinstimmt bzw. deren sinnvolle Konkretisierung ist.

Diese Forderung artikulieren auch Tom deMarco u.a. in ihrem Muster 35 („Testen vor dem Testen“) des legendären Buchs „Adrenalin Junkies & Formular Zombies“. Wer also mir nicht glauben will, ist herzlich eingeladen, es bei diesen Giganten des IT-Projektmanagements nachzulesen.

Wer ist schuld am Scheitern eines Projektes

Der Chaos-Report der Standish Group berichtet regelmäßig über den hohen Anteil an IT-Projekten, die ihre Ziele nur mit großen Abweichungen erreichen und solchen, die überhaupt scheitern. Wie immer man die Kriterien definiert und wie zutreffend die Zahlen auch sein mögen, dass IT-Projekte sehr oft mit erheblichen Schwierigkeiten zu kämpfen haben und ihren Auftraggebern ebenso erhebliche Probleme bereiten, ist unbestritten.

Die Ursachen dafür sind vielfältig. Ich habe schon mehrfach gezeigt, dass vertragliche Regelungen entscheidend zum Gelingen oder Scheitern von Projekten beitragen können. Hier ein umfassender Beitrag dazu mit einigen weiterführenden Links.Wesentliche Faktoren laut Standish Group sind die Projektgröße und die Vorgehensmethodik, ein grundlegender Faktor die sogenannte „Decision Latency“ (Dauer und Aufwand für Entscheidungen sind der Bedeutung der Entscheidung angepasst).

Heute möchte ich mich nicht mit den Ursachen des Scheiterns befassen, sondern mit der Art des Umganges mit Problemen der Projektabwicklung.

Es gibt keine Probleme, nur Herausforderungen

Dieser Satz sollte in jedem Bullshit Bingo einen Sonderpunkt einbringen. Denn es gibt im wirklichen Leben sehr wohl Probleme und es gilt der geniale Satz von Forrest Gump: „Shit happens“.

Ja, es ist natürlich wichtig und richtig, Probleme (auch) als Herausforderungen zu betrachten. Aber dazu muss man Probleme als solche benennen, analysieren und auf dieser Grundlage lösen.

Das Wort „Problem“ zu tabuisieren erinnert mich an das Neusprech („Newspeak“) in Orwells 1984. Wenn etwas sehr schlecht ist, dann ist es „Doppelplusungut“. Diese Sprache wurde von der totalitären Regierung entwickelt, um den gedanklichen Spielraum der Bürger zu beschränken und den Ausdruck von Kritik im Keim zu ersticken. Das funktioniert, schon 1921 hat Ludwig Wittgenstein festgestellt: „Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt.“

Also meine erste dringende Empfehlung: Akzeptiere, dass es Probleme gibt und fürchte dich nicht davor, diese offen als solche anzusprechen. Positives Denken ist nicht Schönfärberei, sondern mutiger Umgang mit Problemen.

Es gibt kein Richtig und Falsch

Immer wieder höre und lese ich diesen Satz. Doch ist dieser Kalenderspruch wirklich ein nützlicher Rat?

Also zunächst ist diese Behauptung einfach falsch. Ich bringe ein krasses Beispiel: Ich gehe ins Krankenhaus wegen eines Meniskusproblems im linken Knie. Als ich aufwache, stelle ich fest, dass mein rechtes Knie operiert wurde. Als ich mich darüber beschwere, sagt der Chirurg zu mir: „Es gibt kein Richtig oder Falsch“?

Nun ernsthaft. Es ist gut, bei der Bewertung von Personen, Plänen, Ereignissen etc. vorsichtig zu sein und immer daran zu denken, dass der erste Eindruck täuschen kann und dass auch ich falsch liegen kann. Ich hatte in den Anfängen meiner Berufslaufbahn einen Chef, der Diskussionen sehr oft und sehr schnell mit dem Statement: „Ich weiß wie’s geht!“ abdrehte. Oft hatte er damit objektiv recht, für die Kreativität und Motivation des Teams war das allerdings kein Turbo. In Druck- oder Gefahrensituationen ist es notwendig und berechtigt, die Entscheidungsfindung einer qualifizierten Person zu überlassen, aber solche Situationen sind die Ausnahme.

Ich weiß natürlich, was mit diesem Spruch gemeint ist. Es ist ein Aufruf zu Toleranz, Geduld, Respekt für unterschiedliche Werte etc. Aber man schüttet das Kind mit dem Bade aus, wenn man das auf alle Arten von Entscheidungen ausdehnt. Wenn ich als Product Owner eine Priorisierung treffe, so ist es im Vorhinein nicht erkennbar, ob diese im Sinne der Ziele und Rahmenbedingungen des Projektes optimal war. Aber das heißt nicht, dass es egal ist, wie ich priorisiere.

Die Theory of Constraints (TOC) definiert klare Kriterien, wie ich zu priorisieren habe: Entlaste den Engpass und ordne alle Aktivitäten dem Bedarf der Engpass-Ressource unter. Es ist nicht leicht, diese Kriterien auf Basis der verfügbaren Informationen korrekt umzusetzen, man kann sich irren oder aufgrund unerwarteter Ereignisse entwickelt sich die Situation anders als erwartet. Aber spätestens in der Retrospektive kann ich erkennen, ob meine Entscheidungen dazu beigetragen haben, die Projektziele zu erreichen, also richtig waren oder falsch.

Auch SAFe gibt Regeln zur Priorisierung vor, nämlich WSJF („Weighted Shortest Job First“) gemäß der Formel: WSJF = Cost of Delay / Job Size. Allerdings ist die Ermittlung der Werte nicht trivial. Allein der leichter abzuschätzende Aufwand für die Umsetzung (Job Size) kann bekanntlich oft erheblich von der Schätzung abweichen. Das heißt natürlich nicht, dass ich bei der Festlegung von Prioritäten genauso gut würfeln kann, weil es ja kein Richtig oder Falsch gibt.

Bitte keine Schuldzuweisungen

Zu einem ordentlichen Projektmanagement gehören Lessons Learned. Aber auch schon während der Laufzeit eines Projektes kommt es immer wieder zu Situationen, wo über Probleme (Pardon: Herausforderungen) gesprochen wird. Der Standardsatz jedes Moderators in solchen Meetings ist die Aufforderung, von Schuldzuweisungen abzusehen. Was ist das Problem?

Jedes größere Projekt findet in einem explizit definierten rechtlichen Rahmen statt. In allen Projektverträgen, die ich jemals gesehen habe, kommt das Wort „Verschulden“ nicht nur einmal vor.

Ich nehme ein aktuelles Beispiel aus einer öffentlichen Ausschreibung: „Der Auftraggeber hat Anspruch auf Geltendmachung einer vom Grad des Verschuldens unabhängigen Vertragsstrafe in Höhe von € #####. … Vertragsstrafen können vom Auftraggeber bis zur Klärung des Verschuldens einbehalten werden“. Es wird ganz klar davon ausgegangen, dass es ein Verschulden geben kann und dass dieses unterschiedlich stark ausgeprägt sein kann. Und es wird unterstellt, dass das Verschulden einem Vertragspartner zugewiesen werden kann, ja sogar muss.

Solange die Probleme eines Projektes nicht so groß sind, dass Juristen einbezogen werden, kann man den Verzicht auf Schuldzuweisungen bei gutem Willen aller Beteiligten praktizieren. Hat man es mit großen Risiken und entsprechend großen Unternehmen als Auftragnehmer zu tun, wird dort im Hintergrund immer ein juristisches Monitoring ablaufen, das alles daran setzt, ein Verschulden des Auftragnehmers abzuwehren.

Solange es darum geht, ein Projekt zum Erfolg zu führen, ist der Verzicht auf Aussagen, die eine explizite Schuldzuweisung sind, unabdingbar. Nur so kann man zu einer lösungsorientierten Diskussion kommen; andernfalls würden die Vertreter des Auftragnehmers bestreiten, dass es ein Problem gibt (ach ja, es gibt ja ohnehin keine Probleme, nur Herausforderungen ). Wenn das nicht gelingt, dann würden sie die Ursache der Probleme in von ihnen nicht beeinflussbaren Faktoren verorten oder dem Auftraggeber zuordnen.

Da selten völlig klar ist, wie ein Problem entstanden ist und vor allem, wie es am besten behoben werden kann, wird mit solchen Auseinandersetzungen wertvolle Zeit verbraucht. Es werden ohnehin knappe Ressourcen gebunden und damit wird das Problem größer als es anfangs war. In diesem Sinne ist es richtig, Schuldzuweisungen so lange wie möglich zu unterdrücken. Auch ich mache das, weiß allerdings aus mehrfacher Erfahrung, dass dieses Schutzschild irgendwann brechen kann.

Ist ein Projekt gescheitert und geht es nicht mehr um Lösungsfindung, sondern um Schadensbegrenzung für die beteiligten Unternehmen, wird nur noch in den vertraglich definierten Kategorien des Verschuldens argumentiert und alles unternommen, um dieses dem jeweils anderen Vertragspartner zuzuweisen.

Der Verzicht auf Schuldzuweisungen im Interesse einer lösungsorientierten Projektarbeit ist ein Balanceakt, den man als Projektmanager*in bewältigen muss. Man schafft einen geschützten Raum und verteidigt diesen so lange wie möglich gegen die „feindliche“ rechtliche Umwelt. In agilen Projekten ist diese Herausforderung besonders groß, wenn nämlich der vertragliche Rahmen den Prinzipien agiler Projektarbeit nicht entspricht. Wenn es möglich ist, sollte man also schon bei der Vertragsgestaltung mitwirken, dann kann aus der feindlichen eine förderliche rechtliche Umwelt werden. Das ist der Grund, warum ich mich im Netzwerk agile.agreement engagiere, mehr dazu hier.

Wie geht man mit Fehlleistungen um?

Ich habe den Chatbot von PMIbefragt, wie man in Lessons Learned damit umgehen soll, wenn ein Teammitglied einen groben Fehler gemacht hat, der für den Projektverlauf erhebliche Folgen hatte. Das war die Antwort, der ich absolut zustimmen kann:

Um in den Lessons Learned mit einem groben Fehler eines Teammitglieds umzugehen, der erhebliche Folgen für den Projektverlauf hatte, sollten Sie einen systematischen und konstruktiven Ansatz verfolgen. Hier sind einige Schritte, die Sie berücksichtigen sollten:

  • Objektive Analyse: Beginnen Sie mit einer objektiven Analyse des Fehlers. Identifizieren Sie die genauen Umstände und Faktoren, die zu dem Fehler geführt haben, ohne Schuldzuweisungen vorzunehmen.
  • Transparente Kommunikation: Besprechen Sie den Fehler offen und ehrlich im Team. Stellen Sie sicher, dass alle Beteiligten die Situation verstehen und die Auswirkungen des Fehlers erkennen.
  • Lernmöglichkeiten: Nutzen Sie den Fehler als Lernmöglichkeit. Diskutieren Sie, was anders gemacht werden könnte, um ähnliche Fehler in der Zukunft zu vermeiden.
  • Prozessverbesserung: Überprüfen Sie die bestehenden Prozesse und Verfahren. Identifizieren Sie Schwachstellen und implementieren Sie Verbesserungen, um die Wahrscheinlichkeit ähnlicher Fehler zu minimieren.
  • Unterstützung und Schulung: Bieten Sie dem betroffenen Teammitglied Unterstützung und Schulung an, um sicherzustellen, dass es die notwendigen Fähigkeiten und Kenntnisse hat, um ähnliche Fehler in der Zukunft zu vermeiden.
  • Dokumentation: Dokumentieren Sie den Fehler und die daraus gezogenen Lehren in den Lessons Learned. Dies hilft, das Wissen für zukünftige Projekte zu bewahren und anderen Teammitgliedern zugänglich zu machen.

Was kennzeichnet eine positive Fehlerkultur

Bei einem meiner frühen Beratungsprojekte wurde ich in das soeben eingeführte Qualitätsmanagementsystem des Kunden integriert und musste bzw. durfte an der Mitarbeiterschulung teilnehmen. Das System war das von Crosby & Associates und der Kernsatz dieses Systems lautet: „Lieber gleich richtig“.  Mit dem Schlagwort „Null-Fehler“ bzw. „Zero-Defect“ wurde diese Strategie bekannt.

Interessant ist allerdings, dass dieser Ansatz in IT-Projekten aktuell keine Rolle spielt. In mehreren Großprojekten, die ich in verschiedenen Rollen begleitet habe, war eine Bug-Statistik selbstverständlicher Teil des Projektcontrollings. Alle Einwände von Anwendervertretern, dass die Fehlerzahl zu hoch sei, wurden als Zeichen mangelnden Verständnisses für das Wesen von Softwareentwicklung weggewischt. Es gibt keine fehlerfreie Software, das weiß man doch!

Ich lese immer wieder in einem Buch von Tom deMarco, das ich generell sehr empfehlen kann. Das Buch gibt es nur noch antiquarisch, das aber sehr preisgünstig und unkompliziert.

Dort berichtet er von einem Gespräch mit zwei Softwareentwicklern, die vor Jahren ein Programm entwickelt hatten, bei dem kein einziger Fehler gefunden worden war. „Ich fragte einen von ihnen, wie er sich denn diesen phänomenalen Erfolg erklärt, ein Programm ohne jeden Bug schon beim ersten Versuch auszuliefern. Er gab mir folgende Antwort: Ähhh, wir haben gar nicht gewusst, dass Bugs erlaubt sind.“ (a.a.O., S. 333). Und weiter schreibt Tom DeMarco: „Es ist unter Softwareentwicklern allgemein bekannt, dass sie niemals den allerletzten Bug aus einem Programm herausbekommen werden. Bugs werden als traurige Lebensweisheit hingenommen. Wir hoffen, sie eines Tages auszumerzen, können sie aber nie endgültig besiegen. Ich bin mehr und mehr über den Gedanken beunruhigt, dass diese fatalistische Haltung Bugs gegenüber kein produktiver Bestandteil unserer Vorgehensweise ist, wie wir an das Problem herangehen, sondern ein Teil des Problems selbst. Ich glaube, wenn wir damit aufhören, uns selbst einzureden, dass Bugs erlaubt sind, würde es weniger davon geben.“ (ebenda, S. 334).

Ja, Fehler kommen vor, aber es sind Fehler und wir müssen einen Lernprozess in Gang setzen, denselben Fehler nicht zweimal zu machen. Um Missverständnissen vorzubeugen: Es geht überhaupt nicht darum, Leute für Fehler niederzumachen. Aber es kann nicht sein, dass man Fehler verschleiert und schönredet.

Ich bin dafür, die Worte „Fehler“ und „Problem“ sehr wohl zu verwenden. Es hilft allerdings, anstatt von Schuld lieber von “ Verantwortung“ zu sprechen. Das hilft. Wenn man allerdings vor Gericht steht, geht es um Schuld. Dann ist das Projekt aber ohnehin schon gescheitert und unser Beitrag als Projektmanager*in ist nicht mehr gefragt.

Prozessanalysen helfen, nützen aber nichts

Ich paraphrasiere den Titel von Dan Ariely’s großartigem Buch „Denken hilft zwar, nützt aber nichts„. Was Denken anbelangt, verweise ich auf sein Buch; zum effektiven Nutzen von Geschäftsprozessanalysen will ich aber meine Erfahrungen und die daraus gezogenen Schlussfolgerungen in diesem Beitrag darstellen.

Wir haben ein Henne-Ei-Problem

„Wir müssen zuerst unsere Soll-Prozesse definieren, denn wir dürfen nicht suboptimale Geschäftsprozesse automatisieren!“, diesen Satz höre ich immer wieder. Völlig richtig ist, dass IT-Projekte Geschäftsprozesse ermöglichen sollen, die optimal auf die Unternehmensziele abgestimmt sind.

Ohne zu wissen, wofür man IT überhaupt einsetzen will, darf man kein IT-Projekt starten. Also startet man eine Geschäftsprozessanalyse ohne Beteiligung der IT, weil man sich ja nicht die Prozesse von der IT vorgeben lassen will. Ich habe schon oft erlebt, dass ein erheblicher Aufwand in solche Analysen investiert wurde, vor allem, wenn man zuerst die Ist-Prozesse im Detail dokumentiert und dann Soll-Prozesse möglichst im gleichen Detaillierungsgrad erarbeitet. Die Enttäuschung war allerdings regelmäßig groß, wenn sich bei der Konkretisierung der Anforderungen an die IT-Anwendungen herausstellt, dass ein Großteil der geforderten Inhalte nicht ohne neuerliche Recherchen und Analysen beantwortet werden kann.

Was sagen die Standards?

PMI definiert im „Business Analysis for Practitioners: A Practice Guide“ folgendes Phasenmodell:

  1. Initiierung: In dieser Phase werden die Ziele und der Umfang der Prozessanalyse festgelegt. Es wird bestimmt, welche Prozesse analysiert werden sollen und welche Stakeholder beteiligt sind.
  2. Anforderungsanalyse: Hier werden die Anforderungen der Stakeholder erfasst und dokumentiert. Techniken wie Interviews, Workshops und Umfragen werden verwendet, um die Bedürfnisse und Erwartungen der Stakeholder zu verstehen.
  3. Prozessmodellierung: Die identifizierten Prozesse werden grafisch dargestellt, um ein besseres Verständnis der Abläufe und ihrer Interaktionen zu ermöglichen. Modellierungstechniken wie BPMN (Business Process Model and Notation) kommen zum Einsatz.
  4. Prozessanalyse: Die Prozesse werden hinsichtlich ihrer Effizienz und Effektivität untersucht. Dies beinhaltet die Identifikation von Engpässen, Redundanzen und Verbesserungspotenzialen.
  5. Prozessdesign: Basierend auf den Analyseergebnissen werden neue oder verbesserte Prozessdesigns entwickelt, die die identifizierten Schwachstellen adressieren.
  6. Implementierung: Die neuen oder verbesserten Prozesse werden in die Organisation eingeführt. Dies kann Schulungen, Anpassungen von IT-Systemen und andere Maßnahmen umfassen.
  7. Überwachung und Kontrolle: Die implementierten Prozesse werden kontinuierlich überwacht und bewertet, um sicherzustellen, dass sie die gewünschten Ergebnisse liefern und um weitere Verbesserungsmöglichkeiten zu identifizieren.

Der Business Process Management Common Body of Knowledge (BPM CBOK) beschreibt einen ähnlichen Lebenszyklus für Geschäftsprozessmanagement mit diesen Phasen:

  1. Prozessplanung und Strategie
  2. Prozessanalyse
  3. Prozessdesign und -modellierung
  4. Prozessimplementierung
  5. Prozessüberwachung und -kontrolle
  6. Prozessverfeinerung und -optimierung.

Der Unterschied besteht vor allem darin, dass PMI naturgemäß den Projektcharakter einer Prozessanalyse stärker akzentiert, während die Association of Business Process Management Professionals International (ABPMP) das Geschäftsprozessmanagement als permanente Aktivität adressiert.

Wann darf, soll oder muss die IT mitreden?

In den Anfängen meiner Projektpraxis dominierte die Aussage, dass man man die Prozesse nicht an die IT-Lösungen anpassen wolle, sondern es nur umgekehrt sein darf. Mittlerweile hat sich das Blatt gewendet. Das Angebot an Standardsoftware ist mittlerweile so groß, dass die Entwicklung von Individualsoftware nach Vorgaben des Business in den meisten Branchen nicht mehr argumentierbar ist. Sowohl die Kosten und die Durchlaufzeit ihrer Entwicklung als auch ihr Beitrag zur Erreichung der Geschäftsziele sind nicht mehr konkurrenzfähig. Zudem ist das Erfolgs- und Kostenrisiko deutlich höher als beim Einsatz von Standardsoftware.

Gerade lese ich in einer Ausschreibung den Satz: „Seitens des Auftraggebers besteht ausdrücklich die Bereitschaft, Prozesse anzupassen, wenn dadurch eine gleichwertige oder bessere Prozessqualität erreicht werden kann und der Anpassungsaufwand der Standardsoftware geringer wird. Diese beiden Aspekte sind im Verlauf der Projektarbeit im Sinne einer Kosten-Nutzen-Analyse abzuwägen.“

Man darf allerdings auch hier nicht von einem Extrem ins Andere verfallen. Es gibt auch unter dieser Prämisse genug zu tun, bevor man sich mit konkreten Softwarelösungen auseinandersetzt.

Vorarbeiten auf Seiten des Business

Das Sammeln von Informationen über den Ist-Zustand kann während der Projektrealisierung viel Zeit ersparen. Das sind die wichtigsten Inhalte, zu denen man am besten ohnehin laufend, spätestens aber beim Start eines IT-Vorhabens Informationen systematisch sammeln sollte:

  • Märkte und Kundensegmente
  • Produkte und Dienstleistungen
  • Geschäftsprozesse (zumindest Prozesslandkarte)
  • Daten
  • Geschäftsregeln
  • Beteiligte Organisationseinheiten und Stakeholder
  • Standorte
  • IT-Systeme (Ist-Situation aus Anwendersicht)
  • Gesetzliche Vorgaben und Compliance-Regelwerke.

Zu jedem dieser Punkte ist eine SWOT-Analyse sinnvoll, um den Änderungsbedarf zu identifizieren und hinsichtlich der Wichtigkeit und Dringlichkeit zu bewerten.

Aber, das ist jetzt die große Einschränkung aus meiner Sicht: Umfang und Detaillierung der Erarbeitung von Soll-Prozessen (Punkt 5 des PMI-Modells bzw. Punkt 3 des BPM CBOK) sollten in dieser Phase nicht zu weit getrieben werden. Es ist durchaus sinnvoll, Soll-Prozesse zu entwerfen, die eine verbesserte Umsetzung der Geschäftsstrategie ermöglichen. Allerdings bringt es wenig, hier zu sehr ins Detail zu gehen, bevor man einen Blick auf die IT-Lösungsoptionen geworfen hat.

Der Blick über den Tellerrand auf vorbildliche Geschäftsprozesse anderer Organisationen und Unternehmen bringt mehr als ein hoher Aufwand für die Detaillierung von Soll-Prozessen auf Grundlage der aktuellen Ist-Situation und der Innen-Sicht.

Wenn man einzelne Geschäftsprozesse schon vorweg im Detail neu konzipiert, dann ist das jedenfalls ein sinnvolles Training für die Herausforderungen der Projektarbeit. Es muss nur allen bewusst sein, dass diese Ergebnisse als Hypothesen zu betrachten sind und im weiteren Verlauf eventuell völlig neu gestaltet werden müssen.

Selbst die unverdächtig erscheinende Empfehlung, sich im Vorfeld eines IT-Projektes über die Ziele und Rahmenbedingungen im Klaren zu sein, ist zu relativieren. Revolutionäre Änderungen des Geschäftsmodells sind in vielen Bereichen erst oder nur mit einer völlig neuartigen IT-Unterstützung machbar. Man bleibt hinter den Möglichkeiten zurück, wenn man ohne Betrachtung der IT-Potenziale Ziele festlegt und Rahmenbedingungen als gegeben nimmt, obwohl sich beides in einem neuen Kontext völlig anders darstellt. Disruptive Änderungen der Geschäftsprozesse ergeben sich fast immer aus neuen Optionen, die aufgrund technischer Innovationen zur Verfügung stehen. Das Internet und E-Commerce sind nicht aufgrund einer Geschäftsprozessanalyse entstanden, gleiches gilt derzeit für die Entwicklungen im Bereich der Künstlichen Intelligenz. KI ist derzeit ein Paradebeispiel für technologiegetriebene Prozessoptimierungen, wobei der Einfluss über die Prozessoptimierung ja weit hinausgeht und vielfach neue Geschäftsmodelle ermöglicht oder gar verlangt.

Vorarbeiten auf Seiten der IT

Die Darstellung aller Aufgaben, die eine kompetente IT-Abteilung (wie immer diese organisatorisch definiert und verankert ist) hier darzustellen, übersteigt den Scope dieses Beitrages. Es übersteigt auch meine inhaltliche Kompetenz. Ich stütze mich in diesem Bereich vorzugsweise auf meinen Freund und Kollegen Wolfgang Keller, der soeben die 4. Auflage seines Buches „IT-Unternehmensarchitektur – Von der Geschäftsstrategie zur optimalen IT-Unterstützung“ veröffentlicht hat.

In den Prozessen „Projektbegleitung“ sowie „Projektprozess“ ist das Zusammenwirken von Business und IT zu verorten. Dass diese Prozesse effektiv und effizient sind, hängt wesentlich davon ab, dass die anderen Prozesse von der IT permanent und professionell exekutiert werden.

Prozesse der IT-Unternehmensarchitektur (W. Keller, a.a.O. S. 394)
Typische Fehlentwicklungen

Unter dem Leitbild der agilen Projektabwicklung wird oft mit IT-Umsetzungen begonnen, ohne dass die notwendigen Grundlagen geschaffen worden sind. Nun habe ich gerade dafür plädiert, gewisse Vorbereitungsaktivität zu reduzieren. Ja, es gibt Aktiväten im Bereich der Prozessanalyse und Prozessoptimierung, die ich aus den dargestellten Gründen zurückschrauben würde. Und es gibt eine ganze Reihe von Aktivitäten, die oft zu kurz kommen (siehe oben).

Dass auch agile Projekte Vorbereitung brauchen habe ich an anderer Stelleschon ausführlich argumentiert und muss es daher nicht weiter ausführen.

Ich beobachte allerdings auch unter agilen Prämissen den Versuch, die Anwender mit immer detaillierteren Anforderungsbeschreibungen quasi festzunageln. Ich hatte schon damit zu kämpfen, dass eine Controllerin die User-Stories „einfrieren“ wollte, weil sonst das Monitoring des Projektfortschrittes nicht möglich sei.

Ebenso habe ich erlebt, dass User-Stories priorisiert werden sollten, obwohl kein Lösungskonzept vorlag, anhand dessen man die Anforderungen hinsichtlich Wichtigkeit, Dringlichkeit, Machbarkeit und Aufwand hätte beurteilen können. Wie komplex das Thema Priorisierung ist, habe ich auch schon an anderer Stellebeschrieben.

Leitlinien für eine gute Praxis

Prozessoptimierung muss sich von Anfang an mit den Möglichkeiten der Informationstechnologie auseinandersetzen, um Leistungspotenziale zu erkennen, die bisher nicht gegeben waren. Es darf weder ein aufbau- noch ein ablauforganisatorisches Konzept finalisiert werden, ohne die technischen Möglichkeiten auf Potenziale für bessere organisatorische Lösungen abzuklopfen.

Aber wie kann das in der Praxis bewältigt werden? Man braucht eine Struktur, in der man diese Flexibilität abhandeln kann. Geeignet dafür ist ein Spiralmodell, das in seinen Grundzügen auf Barry W. Boehm zurückgeht. Dieses Spiralmodell ist ursprünglich im Kontext des Risikomanagements entstanden, mit diesem Vorgehen sollte das Risiko des Scheiterns eines IT-Projektes reduziert werden.

Grundidee des Spiralmodells ist, die unterschiedlichen Themenbereiche immer wieder mit jedes Mal steigendem Detaillierungsgrad zu durchlaufen. Was sind solche Themenbereiche? Es sind die Ziele und Rahmenbedingungen, die Geschäftsprozesse, die eingesetzte Software (Standardsoftware und/oder Individualentwicklung), die zugrunde liegende technische Infrastruktur und natürlich auch die Kosten und der Ressourceneinsatz, der für das Erreichen der gesetzten Ziele notwendig ist.

Nötig ist ein ständiger Dialog zwischen Anwendern und IT. Die Idee, dass Anwender eine Liste von Anforderungen erarbeiten und an die IT übergeben, wird zu keinen besseren Ergebnissen führen, nur weil jetzt Epics, Features und User Stories statt Funktionen in dieser Spezifikation enthalten sind. Man braucht eine Vision für das Geschäftsmodell und die Geschäftsprozesse, in der die Möglichkeiten der IT-Unterstützung bereits berücksichtigt werden. Sicherlich zu Beginn in abstrahierter, möglichst lösungsneutraler Form. Aber durchaus mit Beispielen für mögliche Lösungen aus der Erfahrung der Anwender, auch aufgrund von Erfahrungen in anderen Branchen und im privaten Umfeld. Das kann noch ohne IT-Beteiligung stattfinden, aber je kürzer diese Phase ist, umso besser.

Sobald wie möglich, wird gemeinsam von „Business“ und „IT“ an Lösungen gearbeitet, mit denen die gesetzten Ziele umgesetzt, am besten sogar übertroffen werden können. Aber schon in dieser Phase muss ein Entwurf der Architektur erarbeitet werden und dieser eröffnet eventuell neue Möglichkeiten. Es wird aber auch dazu führen, dass einige Ideen nicht mit vernünftigem Aufwand realisierbar sind und daher verworfen werden müssen. Dann muss der Dialog, die gemeinsame kreative Arbeit, auf dieser veränderten Basis fortgesetzt werden.

Diese Zusammenarbeit endet auch nicht mit dem Start des Projektes. Der/die Product Owner*in kann nicht die einzige Verbindung zwischen der IT und den Anwendern sein, bei jedem größeren Projekt wird dafür ein Team erforderlich sein. Er/sie ist dafür verantwortlich, dass der Dialog, die gemeinsame kreative Arbeit in jeder Phase stattfindet. Die IT ist berechtigt und gefordert, Geschäftsprozesse infrage zu stellen und Vorschläge zu deren Optimierung zu machen, Anwender sind berechtigt und gefordert, die Lösungsvorschläge der IT infrage zu stellen und Vorschläge zu deren Optimierung zu machen.

SAFe betont, dass User Stories keine Anforderungen sind, sondern zitiert Bill Wake, einen der Begründer von Extreme Programming (XP): „Stories act as a ‚pidgin language‘, where both sides (users and developers) can agree enough to work together effectivly“ (S. 209). Solche Mischsprachen sind uns aus vielen Lebensbereichen vertraut, „Denglisch“ ist auch in diesem Text oft vertreten. Von Ron Jeffries, einem anderen Begründer von XP, übernimmt SAFe auch die Charakterisierung von User Stories als „promise for a conversation“ (S. 213). Mit diesem Ansatz, User Stories als ein verbindliches Gesprächsangebot zu sehen, wird die optimale Herangehensweise sehr gut auf den Punkt gebracht.

Die Rolle der Führung im Projektmanagement

Hier als Podcast in englischer Sprache, generiert von Notebook LM

Ist Projektmanagement ein Supportprozess?

Projektmanagement wird oft als administrative Aufgabe verstanden, ich kenne einige Unternehmen, die diese Leistung als Commodity sehen und regelmäßig per Body-Leasing zukaufen. Bei der Auswahl der Projektmanager wird meist darauf geachtet, dass diese zertifiziert sind, in Deutschland und Österreich ist das oft eine Zertifizierung nach IPMA, international dominiert natürlich die Zertifizierung durch PMI, in einigen Ländern ist PRINCE2 stark vertreten.

Die Professionalisierung des Projektmanagements, die mit diesen Standards und den darauf aufbauenden Zertifizierungen einher geht, ist grundsätzlich zu begrüßen. Allerdings rückt dabei oft der Bezug zum Projektinhalt  in den Hintergrund. Inhaltsbefreites Projektmanagement sehe ich sehr kritisch. Ohne ein Verständnis der in einem Projekt zu leistenden Primärprozesse, also die „Herstellung“ der Lieferobjekte, kann man kein Projekt zum Erfolg führen.

Ebenfalls ein Defizit ist aber auch das Fehlen von Führungskompetenz in Projekten. Wird der/die Projektmanager*in zugekauft und ist das Rollenbild wie oben beschrieben das einer Supportfunktion, ist Führung im Sinne von Leadership ohnehin keine Anforderung. Aber Projekte sind Unternehmen auf Zeit und gerade aufgrund ihrer straffen Ziel- und Ergebnisorientierung ist Führung umso mehr unabdingbar.

Führung ist mehr als Projektadministration

Ich habe wieder einmal PMI Infinity gefragt, was man zu diesem Thema wissen sollte. Hier die Antwort (nach nur einem Prompt):

Führung in Projekten ist ein entscheidender Faktor für den Erfolg eines Projekts. Es geht über die bloße Verwaltung von Aufgaben hinaus und umfasst die Fähigkeit, ein Team zu inspirieren, zu motivieren und zu leiten, um gemeinsame Ziele zu erreichen. Hier sind einige wichtige Aspekte der Führung in Projekten:

  • Vision und Richtung: Führungskräfte in Projekten setzen eine klare Vision und Richtung, die das Team inspiriert und motiviert.
  • Kommunikation: Effektive Kommunikation ist entscheidend, um sicherzustellen, dass alle Teammitglieder auf dem gleichen Stand sind und Missverständnisse vermieden werden.
  • Motivation: Führungskräfte müssen in der Lage sein, ihr Team zu motivieren und zu engagieren, um die bestmögliche Leistung zu erzielen.
  • Entscheidungsfindung: Führungskräfte treffen wichtige Entscheidungen, die den Verlauf des Projekts beeinflussen können.
  • Konfliktmanagement: Führungskräfte müssen in der Lage sein, Konflikte innerhalb des Teams zu erkennen und zu lösen, um eine produktive Arbeitsumgebung zu gewährleisten.

Im Gegensatz dazu konzentriert sich die Projektadministration auf die organisatorischen und administrativen Aspekte des Projektmanagements. Hier sind einige Unterschiede zwischen Projektadministration und Leadership:

  • Fokus: Projektadministration konzentriert sich auf die Verwaltung von Aufgaben, Zeitplänen und Ressourcen, während Leadership sich auf die Führung und Motivation des Teams konzentriert.
  • Aufgaben: Projektadministratoren überwachen den Fortschritt, erstellen Berichte und stellen sicher, dass alle administrativen Aufgaben erledigt werden. Führungskräfte hingegen setzen eine Vision, inspirieren das Team und treffen strategische Entscheidungen.
  • Ansatz: Projektadministration ist oft prozessorientiert und folgt festgelegten Methoden und Verfahren. Leadership ist menschenorientiert und erfordert emotionale Intelligenz und zwischenmenschliche Fähigkeiten.
  • Ziel: Das Ziel der Projektadministration ist es, sicherzustellen, dass das Projekt innerhalb des Zeit- und Budgetrahmens abgeschlossen wird. Das Ziel der Führung ist es, das Team zu Höchstleistungen zu bringen und die Projektziele zu erreichen.

Damit ist es klar, wir brauchen beides!

Was macht erfolgreiche Führung aus?

In der Ausgabe Mai/Juni 2017 des Harvard Business Review wurde über eine Studie berichtet, die 4 Faktoren identifiziert, die erfolgreiche von weniger erfolgreichen Führungskräften unterscheidet. Die Autoren sind Personalberater und die Datenbasis sind ca. 17.000 Assessments von Führungskräften auf Geschäftsleitungsebene.

Was sind diese 4 Erfolgsfaktoren?

  1. Schnell und klar entscheiden („Deciding with speed and conviction“)
  2. Ergebnisorientierung („Engaging for impact“)
  3. Proaktiv handeln („Adapting proactively“)
  4. Zuverlässigkeit („Delivering reliably“)

Die Bedeutung dieser Faktoren ist nicht überall gleich, in Branchen mit hoher Veränderungs- und Innovationsrate ist Faktor 3 (Proaktivität) wichtiger als in weniger dynamischen Branchen. Nicht alle erfolgreichen Führungskräfte sind in allen 4 Faktoren stark, aber die besonders erfolgreichen weisen häufiger mehrere positiv ausgeprägte Faktoren auf. Insgesamt am höchsten ist die Wirkung des Faktors 4 (Zuverlässigkeit)

Erfolgsfaktor 1 kann man kurz und pointiert so zusammenfassen: Schnell entscheiden ist wichtiger als richtig entscheiden. Dazu der frühere CEO von Greyhound Stephen Gorman, der das Unternehmen durch einen Turnaround geführt hat: “A bad decision was better than a lack of direction. Most decisions can be undone, but you have to learn to move with the right amount of speed.” Kluge, aber langsame Entscheidungen werden zu Engpässen, dieser Stil strahlt auf alle Mitarbeiter aus, sie werden auch immer vorsichtiger und langsamer in ihren Entscheidungen. Dieser kumulative Effekt verursacht enorme Kosten.

Erfolgsfaktor 2 betont die essenzielle Bedeutung des Stakeholder-Managements. „We found that strong performers balance keen insight into their stakeholders’ priorities with an unrelenting focus on delivering business results“. Allerdings scheuen gerade erfolgreiche Führungskräfte nicht vor Konflikten zurück, wenn diese zur Erreichung der gewünschten Ziele notwendig sind. Ihre Akzeptanz stützt sich nicht auf Wohlfühlfaktoren, sondern auf das Vertrauen der Stakeholder, mit ihnen erfolgreich zu sein. Wichtige Stakeholder sind auch die Mitarbeiter, die Auswahl und Förderung der richtigen Mitarbeiter ist Teil dieses Erfolgsfaktors

Erfolgsfaktor 3 betont die Bereitschaft, Änderungen durchzuführen, wenn sie als notwendig erkannt werden und das frühzeitig und konsequent. Aber gerade deswegen versuchen solche Führungskräfte auch, sich auf Veränderungen frühzeitig vorzubereiten. „Most CEOs know they have to divide their attention among short-, medium-, and long-term perspectives, but the adaptable CEOs spent significantly more of their time—as much as 50%—thinking about the long term. Other executives, by contrast, devoted an average of 30% of their time to long-term thinking“.

Erfolgsfaktor 4 betont Zuverlässigkeit und Berechenbarkeit von Führungskräften als Vorteil gegenüber High-Performern, deren Spitzenleistungen als wahrscheinlich nicht nachhaltig eingeschätzt werden. In diesem Erfolgsfaktor ist allerdings auch das aktive Management der Erwartungen der Stakeholder inkludiert. Unrealistische Erwartungen von Stakeholdern müssen vermieden oder nötigenfalls korrigiert werden, auch wenn das manchmal weh tut. Zuverlässigkeit in diesem Sinne ist also nicht als Opportunismus und bedingungslose Anpassungsbereitschaft zu verstehen. Dazu gehört auch ein hoher Grad an Organisation: „CEOs who ranked high on reliability employed several other tactics as well. Three-quarters of them were rated strong on organization and planning skills. They established business management systems that included a cadence of meetings, dashboards of metrics, clear accountability, and multiple channels for monitoring performance and making rapid course corrections. Most important, they surrounded themselves with strong teams“.

Jeder dieser Erfolgsfaktoren trägt auch dazu bei, Projekte erfolgreich zu führen. Erfolgreiches Projektmanagement erfordert zweifellos hohes Engagement für alle vier Faktoren. Dass Faktor 3 (Proaktives Handeln) in Projekten ebenso wie in Unternehmen mit dynamischem Umfeld besonderes Gewicht hat, scheint mir evident.

Führung ist nicht nur eine Stilfrage (wie?), es geht auch um konkrete Leistungsprozesse (was?)

Die Studie hat das Wie von Führung, den Führungsstil in den Vordergrund gestellt. Der Ton macht die Musik, könnte man salopp sagen. Autoritäte Führung, partizipative Führung, Servant Leadership sind einige der Schlagworte dazu. Die Frage nach effektiver Führung wird häufig auch mit der Schilderung von charismatischen Führungspersönlichkeiten beantwortet, so wird immer wieder Steve Jobs genannt, immer noch, wenn auch immer seltener Elon Musk. Das ist zwar inspirierend, aber nur ein Teil der Antwort auf die Frage, was erfolgreiche Führung ausmacht.

Die Autoren David G. Bowers und Stanley E. Seashore haben ihre Studie „Predicting Organizational Effectiveness with a Four-Factor Theory of Leadership“ im Administrative Science Quarterly, 11(2), 1966 veröffentlicht, damals die führende wissenschaftliche Zeitschrift für Organisationswissenschaften, vergleichbar dem, was heute noch „Nature“ für die Naturwissenschaften ist.

Sie sind der Frage nachgegangen, welche Aktivitäten einer Führungskraft die höchste Hebelwirkung für die Leistung und das soziale Klima einer Organisationseinheit hat. Sie fanden vier Faktoren, die den größten Unterschied ausmachten und aus heutiger Sicht sind das vier Prozesse, die eine Führungskraft managen muss, um erfolgreich zu sein. Meine These ist, dass genau diese vier Prozesse auch für die erfolgreiche Führung von Projekten entscheidend sind.

Prozess 1: Management der Zielklarheit und Zielakzeptanz

z.B.

  • Verdeutlichen der Arbeitsaufgabe des ganzen Teams und jedes einzelnen Teammitglieds
  • Begründung und Erklärung von Vorgaben und Entscheidungen in übergeordneten Bereichen, aber auch eigener Entscheidungen
  • Vertretung der Teaminteressen gegen unvernünftige Vorgaben
  • Mitsprachemöglichkeiten vorsehen.

Prozess 2: Management der Entwicklung der Teammitglieder

z.B.

  • Beachtung und Ausbau der persönlichen Entwicklungsmöglichkeiten
  • Ausbau der beruflichen Fähigkeiten und Kenntnisse
  • Hilfe bei persönlichen Problemen.

Prozess 3: Management der Beziehungen zwischen den Teammitgliedern

z.B.

  • Anstöße zur Zusammenarbeit geben
  • Verändern und Vermeiden von Außenseiterrollen
  • Möglichkeiten der Aussprache schaffen (z.B. regelmäßige Teambesprechungen)
  • Vermitteln bei Konflikten.

Prozess 3: Management der Arbeitsbedingungen

z.B.

  • Bereitstellen geeigneter Arbeitsmittel
  • Beseitigung störender Regelungen und sonstiger Hindernisse der Aufgabenerfüllung
  • regelmäßige und eingehende Information und Schulung.

Bemerkenswert ist, dass diese Prozesse nicht nur von der Führungskraft selbst erfüllt werden können, sondern dass diese in gut funktionierenden Teams in sehr hohem Maße auch von den Teammitgliedern selbst wahrgenommen werden. Es gibt eine wechselseitige Führung ohne eine formelle Vorgesetzten-Mitarbeiter-Rollenverteilung. Die wechselseitige Wahrnehmung dieser Führungsaufgaben (Bowers & Seashore sprechen von „Peer Leadership“) durch die Teammitglieder ist allerdings dort am höchsten, wo auch die Führungskraft sich stark für diese Prozesse engagiert.

Diese Untersuchung zeichnet sich gegenüber anderen Studien dadurch aus, dass die Leistungsmaße in sehr differenzierter Weise erhoben und ausgewertet wurden. Insgesamt wurden für jede Geschäftsstelle eines amerikanischen Lebensversicherungsunternehmens 70 Leistungsmaße sowohl auf der Grundlage betriebswirtschaftlicher Daten als auch Einschätzungen von Vorgesetzten erhoben. Von den insgesamt 100 Filialen wurden 20 aus dem auf diese Weise ermittelten obersten Leistungsbereich und 20 aus dem untersten ausgewählt. Durch die Untersuchung solcher Kontrastgruppen können die für die Leistung ausschlaggebenden Faktoren besonders deutlich erkannt werden.

Was ist zu tun, wenn man führt?

Das für mich wichtige Merkmal des Ansatzes von Bowers&Seashore ist, dass nicht über Eigenschaften von Führungskräften (ob in Projekten oder in einer Linienfunktion) gesprochen wird, sondern über „Jobs to be done“.

Wenn man sich am Prozessmodell orientiert, wird auch klar, dass Führung nicht nur von einer Person wahrgenommen werden muss und kann. Wenn man selbst in einem dieser Prozesse nicht so kompetent ist wie gewünscht und notwendig, kann das im Team aufgeteilt werden. Entgegen der vielfach vertretenen Meinung, es müsse immer genau einen Projektleiter bzw. eine Projektleiterin geben (das „Highlander-Syndrom“), habe ich mit Führungsteams fast immer gute Erfahrungen gemacht; wo diese Erfahrungen nicht positiv waren, lag es am Umfeld oder an einer oder mehreren der beteiligten Personen und wäre bei einer monokratichen Führungssituation auch nicht besser gelaufen.

Den Hinweis auf die Möglichkeit und Mächtigkeit von „Peer Leadership“ habe ich sonst nirgends in dieser Klarheit gefunden. Das Konzept des „Empowerments“ ist damit sicher eng verwandt, wenn auch nicht identisch. Daher meine ich, es lohnt sich auch heute noch, das schon 50 Jahre alte Führungsmodell von Bowers& Seashore zu kennen.

Inhaltsbefreites Projektmanagement als Tugend?

Ich erinnere mich noch gut, dass ein großes internationales Unternehmen postulierte, dass ein guter Manager alles managen kann. Dementsprechend gab es regelmäßige Jobwechsel in unterschiedlichste Bereiche. Ein Freund von mir war dort nacheinander im Consulting, im Softwarebereich und dann im Sales Management für Hardware tätig. Sicher eine grandiose Erfahrungssammlung für ihn. Ob das aus Sicht des Unternehmens die beste Lösung war, ist zu bezweifeln, auch wenn mein Freund jeden dieser Jobs gut bewältigt hat.

Viele Projektmanager denken immer noch so und sehen daher keine Notwendigkeit, sich mit den spezifischen Projektinhalten vertraut zu machen bzw. sich auf bestimmte Projekttypen zu spezialisieren.

Projektmanagement-Standards adressieren die für alle Projekte geltenden Herausforderungen und Lösungsansätze. Das liegt in der Natur solcher Standards und ist ihnen nicht vorzuwerfen. Jedes Projekt hat allerdings einen ganz spezifischen Inhalt. Es geht z.B. um die Errichtung eines Gebäudes, die Entwicklung und/oder Anpassung von Software, die Reorganisation eines Unternehmens, die Einführung eines Produktes am Markt usw. usw.

Je größer das Projekt, umso weniger werden Projektmanager an der inhaltlichen Arbeit beteiligt sein können. Aber immer gilt die Forderung, die in der Projektarbeit auftauchenden Fragen verstehen und beurteilen zu können, ob etwas eine Antwort auf die gestellte Frage ist oder nicht.

Fehlt das notwendige Minimum an inhaltlichem Verständnis, verkommt Projektmanagement zu einer Aufgaben-, Termin- und Aufwandsbuchhaltung. Unverstandenes wird dokumentiert und kommuniziert. Führung fndet nicht statt und die Ergebnisse sind entsprechend.

Meine Kritik an inhaltsbefreitem Projektmanagement ist nachhaltig, über viele Jahre gewachsen und durch Erfahrungen bestätigt. Ich stehe zu dieser Kritik! Aber ich habe auch Konstruktives dazu geschrieben, ich kann den Download dieses Artikels hier anbieten.