Security im agilen Kontext

Diese Tage kam ich in der Diskussion mit einem Kunden auf die Berücksichtigung von Security Requirements in einem agilen Kontext.

Hintergrund war, dass bislang Security vor allem für den Betrieb und für die Produktsicherheit thematisiert wird, aber Sicherheitsaspekte in der Entwicklung und in einer Projektphase noch eher stiefmütterlich behandelt werden. Auf der anderen Seite finden agile Vorgehensweisen immer weiter Einzug in die Unternehmen und die Ausgangsfrage des Kunden war, wie man Sicherheitsbelange im agilen Kontext berücksichtigen kann.

Für die Projektsicht gibt es vor allem zwei Themenstränge (und dabei müssen wir noch nicht mal zwischen agil und klassisch unterscheiden):

  • Die Sicherheit im Projekt
  • Die Entwicklung der Sicherheit für Produkt und Betrieb

Bei letzterem Punkt könnte ich mir unterschiedliche Strategien vorstellen:

  • Ein stufenweiser Hochlauf, bei dem systematisch das Sicherheitsniveau angehoben wird. (Anfangs mit einer Sandbox, dann Aufbau einer Entwicklungsumgebung, erst noch ohne Daten, dann nur mit einem Teilset der Daten, bis hin zur vollumfänglichen Produktion)
  • Vorgabe von Leitplanken (im Qualitätsmanagement gibt es dafür das Control Chart als Werkzeug).

Grundsätzlich würde ich Security-Anforderungen im Normalfall den nicht-funktionalen Anforderungen zuordnen.

Agile SW-Entwicklung fokussiert tendenziell auf funktionalen Anforderungen. Werden dabei wichtige nicht-funktionale Anforderungen vergessen, so kann dies eine Schwäche agilen Vorgehens sein.

Im Wesentlichen finden sich drei Ansätze zur Berücksichtigung von Security Requirements im agilen Kontext:

  • Eigene nicht-funktionale Einträge ins Backlog (beispielsweise eigene User Stories. Ein Kollege hat mir berichtete mir, dass er ein eigenes Backlog für Security Anforderungen aufgebaut hat.)
  • Berücksichtigung nicht-funktionaler Anforderungen als Constraints
  • Berücksichtigung als Kriterien im Definition of Done

Wenn die Vorgaben für Security oder nicht-funktionale Anforderungen allerdings zu sehr formalisiert werden, dann birgt das bereits einen kulturellen Konflikt: Ein formaler Prozess entspricht jetzt nicht ganz den agilen Vorstellungen von eigenverantwortlichem Handeln, d.h. auch da bräuchte es klar definierten Handlungsspielraum für das Team.

Maturity Ansätze fand ich zur Berücksichtigung von Security Anforderungen nicht hilfreich. Da finden sich  CMMI-Adaptionen auf agile Vorgehensweisen. Thematisiert wird aber das Vorgehensmodell an sich und nicht die Berücksichtigung nicht-funktionaler oder sicherheitsrelevanter Anforderungen.

Beitrag #723 auf schlossBlog

Agile Coaches in Großunternehmen

Diese Tage wurde ich zufällig Ohrenzeuge einer kleinen Gruppe von Agile Coaches in einem Großunternehmen.

Erst sprachen sie ihre Einführungsfolien durch („Da sollten wir noch auf die agilen Werte eingehen.“). Das Ganze from the scratch weil agiles Vorgehen #Neuland und so, aber groß im Kommen.

Dann war Mittag und ich durfte einem anderen Gespräch der agile Coaches folgen: „Bist du jetzt schon Senior oder noch Junior? Und wie sieht es mit deiner Zertifizierung aus?“

Klar solches Hierarchie- und Statusdenken ist voll agil.

Steht bestimmt auch im agilen Manifest… Zertifikate vor gesundem Menschenverstand.

Agiles Projektmanagement ohne ein entsprechendes Mindset ist vollkommen sinnlos.

Mit dem richtigen Mindset ist schon fast wieder die Vorgehensweise egal.

Jedes Projekt braucht Agilität. Aber die erreicht man nicht durch die Einführung von agilem Projektmanagement, sondern durch eine entsprechende Einstellung und entsprechende Verhaltenswesien. Aus diesen resultiert dann (vielleicht) wieder ein agiles Projektmanagement oder aber ein open-minded klassisches Vorgehen.

Sinnfrei eingeführtes agiles PM ist genauso bürokratischer Mist, wie jede andere ohne Verstand eingeführte Methode. Mag die Methode an sich noch so gut sein.

Beitrag #721 auf schlossBlog

#679 Fehlerkultur & Resilienz in Projekten

Fehlerkultur und Resilienz tauchen als Begriffe immer häufiger auf und erweisen sich in komplexen Aufgabenstellungen als erfolgreiche Strategie.  Wenn wir schon nicht alles planen und steuern können, dann können wir uns wenigstens auf die Unzulänglichkeiten des Lebens hinreichend vorbereiten. Das gilt in Ausnahmesituationen, ebenso wie im Unternehmensalltag oder in Projekten.

Resilienz mag der Überbegriff sein, aber die Fehlerkultur, als die Art und Weise, wie wir mit Fehlern umgehen ist ein wesentlicher Bestandteil, der zur Resilienz beiträgt. Ein wunderschönes Beispiel dafür, was Fehlerkultur ist, liefert ein Beitrag von Impulse über Fehlermanagement in der Luftfahrt oder: Was Unternehmer von Piloten lernen können.

Und was können sie lernen?  – Das Fehler ganz normal sind und dazu gehören, aber wir können uns auf sie vorbereiten und wenn wir vorbereitet sind, zwingt uns nicht der einzelne Fehler, sondern erst die unglückliche Verkettung mehrerer Fehler in die Knie.

Die Schuldfrage/Cover-your-ass sind unternehmenspolitische Machtspielchen, die nur leider jeden anderen Zweck verfolgen als den Projekterfolg. Mit Fehlerkultur haben sie nichts zu tun. Eher Unkultur…

Resilienz (von lat. resilire ‚zurückspringen‘ ‚abprallen‘) oder psychische Widerstandsfähigkeit ist die Fähigkeit, Krisen zu bewältigen und sie durch Rückgriff auf persönliche und sozial vermittelte Ressourcen als Anlass für Entwicklungen zu nutzen.
(Wikipedia)

Resilienz ist wohl auch eines der Merkmale agilen Projektmanagements, dass dieses so populär macht. Ein zweiter Faktor, der damit Hand in Hand einhergeht sind Kommunikation & Transparenz. Gerade im agilen Projektmanagement werden viele Kommunikationsformen mit Ritualen verstärkt und etabliert. Und last but not least ein spezielles Menschenbild, obwohl das bei der zunehmenden Verbreitung agiler Ansätze immer häufiger vergessen wird. Überhaupt wird der Begriff „agil“ mittlerweile inflationär gebraucht – missbräuchlich gegenüber der ursprünglichen Idee.

Nichtsdestotrotz: Die Erfolgsfaktoren hinter erfolgreichem agilen Vorgehen sind also Kommunikation, Transparenz und Resilienz und auch klassisches Vorgehen kann genauso erfolgreich sein, wenn diese Erfolgsfaktoren gegeben sind. Projekterfolg ist also weniger eine Frage des Vorgehensmodells (agil oder klassisch) als eine Frage der Umsetzung dieser Erfolgsfaktoren (Transparenz, Kommunikation und Resilienz).

#655 Agiles Projektmanagement

Der Vermittler GULP hat seine Datenbank ausgewertet und festgestellt wie und wo die Nachfrage nach agilem Projektmanagement zunimmt:

 

 

Und so sieht es mit der regionalen Verteilung der Nachfragen aus:

#620 Spektrum der Projektarbeit

Projektarbeit muss kontext- und situationsspezifisch sein. Pauschalisierte Ansätze oder Ideologien sind vor diesem Hintergrund Quatsch. Das Spektrum der Projektarbeit (den Managementbegriff habe ich an dieser Stelle bewusst vermieden) ist im Wesentlichen gekennzeichnet durch das gewählte Vorgehensmodell und den praktizierten Führungsstil.

Beginnen wir beim Vorgehensmodell:

Das Spektrum reicht vom Wasserfall bis hin zu agilem, iterativen Vorgehen. Der reine Wasserfall existiert bei genauer Betrachtung eigentlich gar nicht. Nur ein Idiot würde einen einmal gefassten Plan blind in einem Wurf umsetzen. Weitaus häufiger finden sich modifizierte Wasserfallmodelle. Für den Umgang mit Unsicherheit gibt es unterschiedliche Lösungsstrategien: Ein Changemanagement, das Change Requests an ein Projekt behandelt, oder eine iterative Ausarbeitung. Aber auch hier ist die Unterscheidung nicht sinnvoll, weil es auch in der vermeintlich klassischen Projektwelt erlaubt ist iterative Elemente einzusetzen und umgekehrt scheint mir das agile Vorgehen als Postulat genauso überzogen, denn ich kann mir sehr wohl Vorhaben vorstellen, die für den großen Entwurf ein modifiziertes Wasserfallmodell wählen und erst in der Ausarbeitung agil werden, beispielsweise bei der Umgestaltung ganzer Unternehmensarchitekturen. Es gibt ergo keine harten Grenzen.

Auf Seiten des gewählten Führungsstils sieht es ähnlich aus:

Dem humanistischen Ideal des agilen Manifests, ein paritzipatives Modell, weitgehend selbstgesteuert, steht das autoritäre, taylorisitsche Denken gegenüber. Aber auch hier gebe ich zu Bedenken: Der gewählte Führugnsstil muss sowohl zu den Beteiligten und der betroffenen Organisation passen, als auch dem konkreten Kontext gerecht werden. D.h. z.B. dass ein rein agiles Vorgehen an bestimmte Voraussetzungen gebunden ist: Wenn eine Organisation noch nicht bereit ist für ein partizipatives Modell, so wird auch ein agiler Ansatz scheitern. Da hier kulturelle Prozesse betroffen sind, gibt es auch keine schnellen Veränderungen, sondern bestenfalls einen langwierigen, mit Anstrengungen verbundenen Prozess.

Einen zweiten kontextspezifischen Aspekt kann es aus sachlicher Notwendigkeit geben: Bei einem Notfall oder einem Rettungseinsatz, wird man schwerlich die Autortität des Einsatzleiters hinterfragen. Hier gibt es Notwendigkeiten in der zeitlich/sachlichen Koordination, die eine Unterordnung erfordern. Dies ist aber kein blinder Gehorsam, sondern lediglich eine situationsspetzifische Unterodnung. Sobald die sachliche Notwendigkeit entfällt besteht auch wieder die Möglichkeit zu Partizipation und autonomen Handeln.

Ein dritter und letzter wesentlicher Punkt bei der Wahl des Führungsmodells stellt die erforderliche Expertise dar. Die Tayloristische Arbeitsteilung wird allzu schnell auf ihre arbeitspsychologischen Nachteile reduziert. Ein weiterer Aspekt (und auch ein Vorteil) liegt in der Spezialisierung (und Expertise). Die Annahme eines SCRUM-Teams, in dem jeder theoretisch jede Aufgabe übernehmen kann, ist illusorisch. Natürlich gibt es komplexe Aufgaben die sinnvollerweise einem Experten zugeordnet werden. (Wer beispielsweise mal einen EDI-Experten in einem Unternehmen kennengelernt hat, weiß wovon ich spreche…)

Der Versuch die existierenden Schulen/Ansätze in diesem Spektrum zu verankern ist zugegebenermaßen gewagt und im Detail zwangsläufig auch falsch.

Ich möchte zwischen den verschiedenen Vertretern des „klassischen“ Projektmanagement (so fragwürdig dieser Begriff auch immer ist) gar nicht differenzieren und Scrum ist auch nur ein Vertreter der agilen Welt. Mittlerweile gibt es auch bei den „klassischen“ Vertretern  immer mehr das Aufrgreifen agiler Ansätze und umgekehrt in der rein agilen Welt muss man sich auch den Realitäten stellen: Wenn der Kunde sich nicht einbinden lässt, dann muss auch der Product Owner neu interpretiert werden. Und wenn dann die Voraussetzungen nicht passen, dann sieht auch ein Scrum Master genauso alt aus, wie ein im Stich gelassener klassischer PM.

De facto geht es halt doch nicht ohne eine kontextspezifische Betrachtung: Wichtiger als das Vorgehensmodell sind die konkreten Umstände. Welche Stakeholder sind eingebunden, nehmen welche Rolle war? Rollen lassen sich zum Teil nur definieren, zum Teil sind sie einfach nur gegeben. Ein gut eingebundener Kunde ist der Traum eines jeden Projetarbeiters – egal ob agil oder klassisch. In der Realität muss man den Kunden nehmen, den man hat. Das Leben ist kein Wunschkonzert.

#618 Beyond Project Management

Dies ist mein Beitrag zur Blogparade von Marcus Raitner zum diesjährigen Motto des PM-Camp Dornbirn.

Projekte werden bleiben. Und sie werden wichtiger denn je. Nichtsdestotrotz gibt es diesen Wunsch nach einem „beyond project management“ zu verzeichnen und auch dieser Wunsch ist durchaus nachvollziehbar:

  1. Es gibt eine wahre Inflation an Projekten („Projektitis), d.h. vieles (egal ob es sich um ein Projekt handelt oder nicht) wird in ein Projektkorsett gepresst. Da wird ein Projekt schon mal schnell zum Formalismus und der gesunde Menschenverstand bleibt auf der Strecke.
  2. In der Projektarbeit wird glatt vergessen, dass es bei Projekten um komplexe Problemlösungsaufgaben geht, stattdessen wird mit Patentrezepten nach schnellen Lösungen gesucht.
  3. Innerhalb des Projektmanagement gibt es seit Jahren Abgrenzungskämpfe: Einmal zwischen den Verbänden (GPM, PMI,…) und zum Anderen klassisch vs. agil.

An (1) sind aktuelle Management-Strukturen nicht unschuldig: Projekte werden als Werkzeug zur Unternehemenssteuerung eingesetzt – nein: missbraucht. Da sind Projekte das Vehikel beispielsweise der Budgetplanung und wenn für ein Thema Budget gebraucht wird, dann plant man dafür ein Projekt – unabhängig von Art und Charakter der Aufgabe. Außerdem will man alle Projekte miteinander vergleichen können und die Dashboards und KPI´s in denen das Portfolio dargestellt werden, sind der Traum des Managements, aber mitunter des Albtraum der Projekte, denn komplexe Sachverhalte auf Kennzahlen zu reduzieren ist nicht nur mutig, sondern auch gefährlich. Vielleicht steckt hinter „beyond project managememt“ also mehr ein „beyond management„.

Bei (2) möchte ich von einem Komplexitätsdilemma von Projekten sprechen (siehe auch die Betrachtung im Rahmen der Design Thinking Reihe). Die Komplexität der Aufgabenstellung ist einerseits konstituierendes Merkmal eines Projektes, andererseits verdrängen wir das sofort wieder in dem wir uns auf die Suche nach der einen Lösung machen, egal ob im großen Wurf oder in inkrementalen Schritten. Wenn wir uns das Komplexitätsdilemma bewusst machen, ist es kein Wunder, warum so viele Projekte scheitern. Vielleicht brauchen wir hier einen Perspektivenwechsel: Weg von der Erfolgsbetrachtung des einzelnen Projekts, hin zu einer Entwicklungs- und Lernperspektive.

Ad (3): Ich bin ganz bei Stefan Hagen und Reinhard Wagner: Die künstlichen Abgrenzungsversuche sind reiner Quatsch. Was die Scharmützel der Verbände angeht, so sehe ich diese v.a. als Ergebnis der ökonomischen Interessen des mittlerweile auswuchernden Zertifizierungsbusiness (aber das ist eine andere Diskussion). Die vielen unnötigen Diskussion agil vs. klassisch der letzten Jahre gehen mir mittlerweile reichlich auf den Senkel. Zunächst muss man feststellen, dass dieses „klassische Projektmanagement“ erst von den „Agilisten“ erfunden wurde, nämlich im Versuch der Abgrenzung. Wir sind uns sicher schnell einig, dass es viele fragwürdige und überholenswerte Methoden und Vorgehensweisen gibt, die wir gerne anpacken sollten, aber bitte keine Glaubenskriege. Es gibt keinen Grund ein humanistisches Menschenbild, iterative Vorgehensweisen, Selbststeuerung und Teams in Projekten (á la Agiles Manifest) abzulehnen. Das tut auch keiner – nur die Abgrenzung klassisch vs. agil. Es gibt nur ein Welt, aber diese mit sehr vielen Facetten und vielen unterschiedlichsten Versuchen die Fragen dieser Welt zu beantworten. Primär ist für mich dir Frage nach dem Kontext entscheidend und nicht die Frage nach der Schule mit der ich versuche einen Kontext zu bearbeiten. Somit schließt sich wieder der Kreis zur Argumentation von Stefan Hagen und Reinhard Wagner.

#609 visualPM: klassisch, agil – Design Thinking

Auch wenn wir hier etwas einseitig auf die Prozessperspektive des Design Thinking blicken, so ist das doch ein hilfreicher Ansatz um auch Projektmanagement-Schulen zu reflektieren.

Das „klassische“ PM unterstellt fast schon tayloristisch den „one best way“ zum Projektziel, der anfangs geplant und dann konsequent sequentiell in einem Wasserfallmodell abgearbeitet wird. Dieses Bild ist natürlich stark vereinfacht, denn auch die „agilen“ Oesterreich und Weiß weisen bereits darauf hin, dass die Väter des Wasserfallmodells durchaus (Rück-)Sprünge zwischen Prozesschritten/-phasen gesehen haben.

Im agilen PM wird die Idee der Umsetzung auf dem direkten Weg in einem großen Wurf aufgegeben. Der Fokus bleibt zwar auf der Umsetzung einer Lösung, aber nicht auf der Umsetzung eines großen Plans, sondern auf der Umsetzung der Anforderungen im Backlog in vielen kleinen Schritten/Iterationen. Iteratives Vorgehen lässt bewusst Platz für permanente Changes, die den klassischen PM doch in Verzweiflung treiben. Schrittweises Vorgehen und die permanente Integration erlauben von Anfang an einen Lernprozess. Risiken werden durch die laufende Integration minimiert, da Fehler schnell erkannt werden und korrigiert werden können. Änderungen können problemlos in den laufenden Prozess einfließen. Was gerne vernachlässigt wird ist aber, dass agiles PM auch einige implizite Annahmen mit sich bringt, z.B. bzgl. der Skalierbarkeit von Anforderungen/Features und der Skalierbarkeit des Teams.

Während diese beiden Ansätze also auf die Umsetzung von Anforderungen fokussieren, fokussiert Design Thinking auf den kreativen Prozess, auf die Gestaltung und Problemlösung. Wir entwickeln ja erst die Lösung und auch nicht die EINE Lösung, sondern möglicherweise erst einmal eine ganze Reihe verschiedener Lösungsansätze, die wir parallel verfolgen und weiterentwickeln, bevor wir uns für eine Variante entscheiden. Wir suchen quasi die Lösung für ein komplexes Problem, statt von Anfang an einen mehr oder weniger komplizierten Plan zu verfolgen.

STOP. Denkpause.

Aber eigentlich ist doch Komplexität ein konstituierendes Merkmal der Projektdefinition. Heißt das dann nicht im Umkehrschluss, dass wir im Projektmanagement (egal ob klassisch oder agil) auf der Suche nach dem einen Weg zum Ziel die Komplexität (trotz besserem Wissen) ignorieren bzw. vernachlässigen?

Kein Wunder, dass so viele Projekte scheitern…

Umgekehrt benötigt der kreative Prozess aber Freiraum, Zeit und Ressourcen. Er ist vielleicht effektiv, aber möglicherweise nicht so effizient, wie es sich der eine oder andere Stakeholder erhofft.

Folgende Grafik skizziert noch einmal die drei Herangehensweisen, vom klassischen direkten Weg zum Projektziel, über das agile Herantasten, bis hin zur parallelen Entwicklung von Lösungsalternativen im Design Thinking:

#607 visualPM: „Sprünge“ im Design Thinking Prozess

Wie bereits im vorangegangenem Beitrag angesprochen: Design Prozesse sind „sprunghaft“. Sie erlauben nahezu beliebige Sprünge zwischen den einzelnen Prozessschritten. Der Design Prozess ist kein Wasserfall-Modell, das sequentiell durchlaufen wird.

Das obige Bild zeigt anhand des Design Thinking Prozess des HPI, dass aufgrund neuer Erkenntnisse oder Ideen, jeder Prozessschritt beeinflusst werden kann und es vor allem zu Sprüngen zurück im Prozess kommen kann. Design Prozesse bekommen so eine eigene Agilität, wobei diese nicht wie im agilen Projektmanagement in geplanten Iterationen erfolgen muss. Design Prozesse sind hier weit freier, losgelöst von organisatorischen Hilfskonstrukten wie Iterationen oder getakteten Sprints. Auch optimierende Betrachtungen von Velocity oder Burn-Down-Charts gibt es natürlich nicht. Wir sind ja auch in einem kreativen Prozess und nicht in einem (reinen) Produktionsprozess.

#577 Meine Vorurteile über agile Frameworks

Auch wenn man mich vielleicht primär dem klassischen Projektmanagement zurechnen würde, so bin ich agilem Denken und agilen Methoden mehr als aufgeschlossen. Wer ein humanistisches Weltbild hat, hat auch mit den Idealen des Agilen Manifests kein Problem. Iterative Vorgehensweisen waren da, wo sie einsetzbar sind schon immer eine hervorragende Strategie um Risiken zu minimieren und Quick-Wins zu realisieren. An meine Grenzen stoße ich bei den verschiedenen agilen Frameworks aber an zwei Stellen:

  1. Ihrer Ideologisierung
  2. Der Formalisierung

Im ersten Punkt kommt es häufig zu dem Missverständnis, dass wer nicht „agil“ auf seinen Fahnen stehen hat, wohl auch agile Werte nicht teilt und unterstützt.

Im zweiten Punkt missfällt mir die idealtypische Formalisierung der Vorgehensweisen und Rollen in den agilen Frameworks. Wenn mein Kunde sich ebenfalls im Projektteam adäquat einbringt und idealerweise die Rolle des Product Owners einnimmt und ich eine offene und konstruktive Projektkultur habe, dann ist das ein Idealzustand, der in klassischen Szenarien ebenfalls hervorragend funktioniert, wenn dort die Rolle entsprechend beispielsweise im Anforderungsmanagement und in meinen Gremien besetzt ist und wahrgenommen wird. Erfolgsfaktor ist dann aber nicht das Framework, sondern die wahrgenommene Verantwortung und die gelebte (Projekt-)Kultur.

Ein Aha-Erlebnis hatte ich in der Lego for Scrum-Session von Tilman Moser auf dem PMCampRM. Tilman ließ uns in drei Scrum-Teams in drei Sprints an einer Lego-Stadt bauen. Ziel war Scrum „erfahrbar“ zu machen. Dadurch, dass das Spiel in einen Session-Slot gezwängt wurde, unterlag der Aufbau von Anfang an vielen Restriktionen und Abkürzungen. Schätzungen Retrospektiven kamen zu kurz und Tilman genoss es auch sichtlich seine Rolle als Product Owner in vollen Zügen auszureizen. Dieser nicht-ideale Aufbau mag Fehlentwicklungen im Verlauf erklären, ich halte ihn aber trotzdem für realistisch, weil wir auch in Scrum-Projekten nicht nur mit Gutmenschen zu tun habe, auch diese unter Stress und wandelnden Anforderungen, etc. stehen.

Bemerkenswert war, dass schon in diesem kleinen Aufbau die Gruppendynamik voll zuschlug und das leider nicht in dem Sinne, wie es Scrum vorsieht, sondern im schlimmsten tayloristischen Sinn. Dabei hatten wir zufällig sogar einen ausgebildeten Scrum Master an Board, aber die Denk- und Verhaltensweisen in unserem kleinen Team erinnerten mich eher an die aus den Modellen der Akkord-Arbeit bekannte Phänomene, als an agile Ideale. Nicht wissend, was wir zu erwarten hatten, waren wir in der ersten Sprint-Planung sehr zurückhaltend. Als wir dann noch die ersten Missverständnisse mit unserem Product Owner hatten und auch unsere Möglichkeiten zur Kommunikation mit ihm innerhalb der Sprints gar nicht genutzt haben (Es waren ja nur 5 Minuten je Sprint, aber trotzdem: Wir haben es nicht getan!). Als er uns dann – mit Genuss (Schweinebacke!) am Ende des ersten Sprints auflaufen ließ, schalteten wir sofort auf Abwehrverhalten um: Bloß keine Blöße geben, Preise nicht verderben,… Ganz 1.0 halt.

Jetzt war der ganze Aufbau „nur“ ein Spiel unter zugegeben ungünstigen Voraussetzungen, aber ich habe dabei mit Schrecken meine Vorurteile bestätigt gefunden. In einer nicht idealen Welt stoßen auch agile Frameworks an ihre Grenzen.

#569 PM – Abschied vom Management

Die Betrachtung von Erfolg und Scheitern von Projekten wurde auf dem PM-Camp in Stuttgart auf die Meta-Ebene gehoben (hier in der Session-Doku auf openPM oder hier auf schlossBlog).

Die erste Konsequenz aus dieser Diskussion lautet ganz banal:

Scheitern gehört dazu. Scheitern ist ganz normal, auch wenn uns Gott und die Welt etwas anderes erzählen wollen. Die Studien von Gartner & Co haben es schon immer gesagt, aber wir wollten es einfach nicht wahr haben und haben das Stigma des Scheiterns gepflegt.

Ich würde sogar noch weiter gehen und die folgende These aufstellen:

In Projekten zeigt sich die Fähigkeit einer Organisation zur Veränderung und Selbsterneuerung.

Das Scheitern einzelner Projekte stellt lediglich die Lernkurve in einer solchen organisatorischen Entwicklung dar und ist unumgänglicher Bestandteil.

Kritisch wird es aber, wenn eine Organisation oder Gesellschaft gar nicht mehr in der Lage ist Projekte erfolgreich durchzuführen. Nicht das Scheitern ist zu verurteilen, sondern das Ignorieren des Scheiterns. Nicht das Scheitern des Euro-Hawk-Debakels ist zu verurteilen, sondern dass die Notbremse erst (geschätzt) mehr als ein Jahr nach dem Bekanntwerdens gezogen wird. Natürlich ist der Verlauf von BER desaströs, aber es hat erst den alten Haudegen Mehdorn gebraucht um triviales PM-Turnaround-Management zu starten, Know-How zu sichern, Risiken z.B. durch eine gestaffelte Inbetriebsetzung zu minimieren, fatale Terminaussagen zu kippen und jenseits eines reinen Rechtfertigungsdenkens die Projektarbeit wieder fortzusetzen.

Angesichts des heutigen Umgangs mit Großprojekten stellt sich berechtigt die Frage, wie weit die bundesdeutsche Gesellschaft noch diese Fähigkeit zur Veränderung und Selbsterneuerung besitzt.

Ein weiterer wichtiger Impuls aus dieser Sicht auf das Scheitern von Projekten ergibt sich für die Business Case-Betrachtung: Wie weit macht die heute übliche Praxis Business Cases für Projekte zu berechnen noch Sinn? Wenn wir die hohe Quote des Scheiterns berücksichtigen, ist nahezu jede Business Case-Betrachtung, die wir kennen vollkommen utopisch. Ich habe auch kein Patentrezept hierfür, aber wir brauchen diese Selbsterkenntnis, wenn wir uns mit den entsprechenden Modellrechnungen beschäftigen.

Der im voranstehenden Beitrag zitierte Gunter Dueck beziffert die Erfolgswahrscheinlichkeit von Innovationsprojekten bei 5% und unter optimalen Umständen, wenn entsprechende Investoren mit den erforderlichen Managementfähigkeiten vorhanden sind auf 11%.  Venture Capitalists berücksichtigen solche Zahlen in ihren Kalkulationen, d.h. sie gehen davon aus, dass von 10 Investitionen vielleicht nur eine fliegt, aber diese muss dann auch die Kosten der anderen decken. Übertragen auf das ganz normale Projektmanagement in Organisationen, heißt dass, dass der Business Case sich eben nur über alle Projekte und i.d.R. nicht für ein einzelnes Projekt rechnet, aber wie lösen wir die Wirtschaftlichkeitsbetrachtung vom einzelnen Projekt und heben sie auf die Ebene des Portfolios?

Bleiben wir noch einen Augenblick bei Dueck und dem Thema Management-Fähigkeit: Dueck rechnet gnadenlos mit den Alibi-Management-Funktionen in (zumeist Großunternehmen) ab. Und fordert eine Abkehr von einem solchen Management. Sein Antwort-Ansatz geht Richtung agilem (Projekt-)Management. Diese Sicht teile ich nur mit Einschränkungen. Ich sehe durchaus weiterhin eine Berechtigung von klassischen PM-Ansätzen (neben agilen Methoden), sofern sie sich von den von Dueck zu Recht kritisierten Management-Attitüden verabschieden. Weshalb ich agile Ansätze nicht für die alleinige Lösungsmöglichkeit halte liegt zum Einen daran, dass auch agile Methoden eigene Attitüden mitbringen (können) und zum anderen, dass sich nicht jedes Problem in die im Agilen beschriebenen Scheiben schneiden lässt –  es gibt auch Elefanten, die tot sind, wenn man sie in Scheiben schneidet.

Für den von Dueck kritisierten Management-Begriff sollten wir auch im PM keinen Platz mehr lassen. Die Lösung würde ich aber nicht rein im Agilen suchen, sondern in einem anderen Buch Duecks: Professionelle Intelligenz könnte der Schlüssel sein. Wir brauchen eine Professionalisierung und gesunden Menschenverstand statt eines Rechtfertigungsmanagements um Veränderungsprozesse zu bewerkstelligen und auch um vielleicht in dem einen oder anderen Projekt mehr erfolgreich zu sein.