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.

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 (Amazon Affiliate Link) 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.

Unter diesem Titel setzt sich ein Beitrag auf den Webseiten der IG Metall mit dem Wandel in der ITK-Industrie auseinander und bemängelt, dass der Mensch dabei auf der Strecke bleibt. Die Rede ist von IT-basierten Lean-Konzepten für die Kopfarbeit und dabei wird alles in einen Topf geworfen: Agile Methoden, Mobiles Internet, Intelligente Netze, Cloud Computing, Social Media, Crowd Working. Beispiele werden u.a. von HP, Nokia Siemens Networks, IBM und SAP angeführt.

Aus gewerkschaftlicher Sicht wird bemängelt, dass die Global Player in diesem Umfeld verstärkt auf Offshoring, Outsourcing, transnationale Projekt- und Teamarbeit sowie Crowd Working-Strategien setzen.  In kleineren Betrieben würden sich die Arbeitsbedingungen u.a. aufgrund von Fachkräftemangel bei zunehmender Arbeitsbelastung verschlechtern. Als Risiken der Veränderungsprozesse werden attestiert:

Prekäre Beschäftigungsformen wie Leiharbeit und Scheinselbstständigkeit nehmen ebenfalls zu. Damit verbunden sind häufig wachsende gesundheitliche Belastungen, allgemeine Verunsicherung und psychischer Druck in einem „System permanenter Bewährung“ (Boes/Bultemeier).

Das so gezeichnete Bild entspricht so gar nicht den idealistischen Vorstellungen agiler Methoden. Liegt doch beispielsweise dem agilen Manifest ein ganz anderes Menschenbild zugrunde.  Jurgen Appelo würde das oben beschriebene Szenario als ein Management 2.0 bezeichnen, die Umsetzung von Methoden wie Leanmanagement, TQM & Co in hierarchischen Systemen. (Dabei liegt eigentlich auch dem Leanmanagement ein ähnliches Menschenbild zugrunde, das in der Verkürzung aber auf der Strecke bleibt und mittlerweile fast schon in Vergessenheit geraten ist.) Jurgen postuliert stattdessen ein Management 3.0 (Amazon Affiliate Link) mit der Einführung agiler Methoden  und der Abkehr von hierarchischen Systemen.

Bei agilen Methoden liegt die Betonung i.d.R. auf Selbstorgansiation und Selbstbestimmung und eine mögliche Überforderung á la Boes/Bultemeier wird nicht weiter diskutiert. Allerdings reagieren agile Vertreter auf die Verknüpfung agiler Methoden mit klassischem Optimierungsdenken, wie bei Wolfram Müllers High-Performance Projektmanagement auf openPM oder bei seinem Beitrag auf dem PM-Camp in Dornbirn durchaus dünnhäutig. Offenbar sieht sich die Zunft gerade nicht gerne als neues Produktionsmodell.

Persönlich missfallen mir die idealisierten Rahmenbedingungen agiler Ansätze, weil sie häufig utopisch sind. Wenn ich den idealen Product Owner, am besten gleich noch auf Kundenseite, von Anfang an engagiert und eingebunden in meinem Projekt habe, dann sind das Voraussetzungen, die auch jedem klassischen Projekt gut tun würden, die nur in der Realität nicht immer anzutreffen sind. Erfrischend hier wieder Jurgen Appelo, der jüngst in einem Blogbeitrag das imperfekte agile Vorgehen postuliert: Don´t let Scrum make you fragile. Er plädiert dafür Methoden wie Scrum nicht Buchstabe für Buchstabe umzusetzen, sondern auch Platz für Variabilität, Unsicherheiten und Überraschungen zu lassen. Ich fürchte nur, dass deutsche Gewerkschaften dies der arbeitenden Bevölkerung nicht zutrauen und deren permanente Überforderung anprangern werden…

Um gleich das Fazit vorweg zu nehmen: APM ist das Buch über agiles Projektmanagement, dass ich mir schon eine ganze Weile erhofft hatte. Es mag neuere Werke geben, andere, die mehr sexy sind, aber hier schaffen es die Autoren die Kluft zwischen agil und klassisch zu überwinden.

Entgegen anderen agilen Ansätzen, wie z.B. dem SCRUM-Framework, verzichten Sie darauf ein komplett eigenes Setup von Rollen und Bezeichnungen zu generieren, sondern suchen – im Gegenteil – die Anschlussfähigkeit zur klassischen Welt: In diesem Fall an den PMBOK des PMI. Sie räumen auf mit agil klassischen Vorurteilen z.B. über das Wasserfallmodell und zeigen dessen agile Wurzeln.

Das Buch gliedert sich in 2 Teile: Teil 1 beschreibt das APM-Verfahren als agile Vorgehensweise  von der Projektvorbereitung, über die Projektplanung, Releaseplanung, Iterationsvorbereitung, Iterationsdurchführung, Iterationsnachbereitung, bis hin zum Release. und Projektabschluss. Teil 2 beschreibt Techniken, Muster, Modelle und Standards und kann quasi auch als Methoden-ABC gelesen und als Nachschlagewerk genutzt werden. Nur ein Schluss fehlt irgendwie.

Auf der oose-Homepage (aus dieser Werkstatt stammt das Buch) ist das Werk samt Downloads aber leider wieder verschwunden, dafür gibt es zum Buch ein Poster mit den zentralen  Slides.

Bernd Oestereich, Christian Weiß
APM – Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte (Amazon Affilliate Link)
dpunkt-Verlag
Heidelberg 2008

Eberhard Huber hat sich in einem Vortrag mit „des Pudels Kern“ des agilen PM befasst, aber nicht rein theoretisch, sondern auf Basis seiner empirischen Studie:

• Was ist des (agilen) Pudels Kern?
• Folien und Literaturtipp
• Fragen an den Vortrag

Sebastian Schneider hat drei elektronische KANBAN-Boards ausgegraben.

Einen offenen PM-Standard, unabhängig von Verbänden wie, GPM, PMI oder anderen propagiert Marcus Raitner und kündigt bereits an, dass wir auf dem PM-Camp darüber diskutieren werden.

Am 25. und 26. Oktober findet das PM Forum der GPM in Nürnberg statt. Als Vorgeschmack gibt es in der Reihe PM 10 minutes ein Interview von Andreas Heilwagen mit Ed Hoffman von der NASA, dem Keynote Speaker der Veranstaltung.

Marcus Raitner hat als Teaser für das PM-Camp auf Google+ gepostet:

Lasst uns gemeinsam die neuesten Trends im Projektmanagement gestalten:

– Klassisches vs. agiles Projektmanagement
– Hierarchie / Linie vs. Heterarchie / Teamorientierung
– Fremdorganisation vs. Selbstorganisation
– Management vs. Führung
– Planung vs. Improvisation

Mich stört nur das „vs.“.

Müsste es nicht „und“ heißen?!

Immer wieder werden an dieser Stelle Blogger wie Stefan Hagen, Andreas Heilwagen, Marcus Raitner oder andere zitiert. Auf PROJEKT-LOG findet sich die Interview-Reihe „7 interessante Antworten von…“ mit Interviews mit den Kollegen.

Eine interessante These von Peter auf Agile Scout: Thomas Edison Created First Agile Organization.

Die Bedeutung von Teams für den Projekterfolg ist elementar. Judith Andresen beschreibt uns auf Slideshare Ihren Weg zum perfekten Team.

Und auch in Marcus Raitners Reihe Projektcoaching geht es weiter:

24 – Verunsicherung
25 – Verteilte Teams
26 – Verbindlichkeit

Eberhard Huber spricht von „Target hopping“ und lässt uns an seinem Leid über Moving Targets teil haben. Dabei wissen wir doch alle (und nicht nur Glen B. Alleman, der darüber bloggt): „Plans are meant to be changed„.

Eine kurze Zusammanfassung zu PM-Themen aus meinem Feedreader:

• Marcus Raitner bloggt jetzt seit einem Jahr! Herzlichen Glückwunsch und weiter so! In seiner Reihe Projektcoaching sind zuletzt erschienen: 16 – Glaubenssätze, 17 –  Effektivität, 18 – Flöhe hüten und 19 – Informationsfluss
• Stefan Hagen fragt (rhetorisch), ob Projektmanager ein undankbarer Job ist und plädiert dafür, dass Unternehmen die entsprechenden Rahmenbedingungen schaffen sollten.
• Computerwoche: Erfahrung zählt im Projektmarkt – Erst festangestellt, dann freiberuflich
• Andreas Heilwagen hat bei Mike Griffith den Versuch ausgegraben PMBOK und agile Prozesse aufeinander zu mappen.
• Was für eine Metapher! Für Brad Egeland riechen neue Projekte wie ein frisch geschnittener Rasen.

Hier wieder Hinweise auf lesenswerte Beiträge der PM-Community:

• Andreas Heilwagen fragt sich, was ein Scrum Master macht, wenn er nicht „mastered“.
• Und nochmal Andreas mit dem dritten Teil seines Video-Podacsts mit Oliver Lehmann zum Thema PM und Spieltheorie.
• Im Ehrenamt stösst man mit professionellen Ansprüchen mitunter an Grenzen. Susan Peterson gibt sich auf PM Hut damit nicht zufrieden und versucht den Weg für ein professionelles Projektmanagment auch in Freiwilligenorganisationen aufzuzeigen.
• Peter Taylors These „PMOs shouldn´t forget the project manager“ sollte zwar selbstverständlich sein, doch seine Mahnung scheint mir durchaus angebracht. Reporting und Portfolio-Verwaltung verselbständigen sich mitunter. Weiter beschreibt er, welche Arten eines PMOs es gibt und was ein PMO alles „kann“.
• Passend zur Jahreszeit fragt Danny Quick, ob agiles Projektmanagement dem Weihnachtsmann hilft.
  Die Weihnachtswünsche seines Sohnes dienen ihm als plastisches Beispiel. Wenn ich an meine eigenen Kinder denke, zeigen sich hier allerdings die Grenzen agiler Methoden: Weder entwickeln sich die Anforderungen kontinuierlich noch ist eine Stabilität der Anforderungen gegeben. Sie ändern sich diametral von Tag zu Tag.
  Will man als Weihnachtsmann/Projekt wirklich jeden Ausschlag der Kundenwünsche mitmachen? Als Eltern würden wir hier sicher anders agieren und bestimmte Annahmen über unseren Nachwuchs treffen. Und – wie im richtigen Projektleben – an Weihnachten gibt es  trotzdem strahlende Kinderaugen, die längst wieder vergessen haben mit welchen Anforderungen sie uns im Vorfeld traktiert haben…
  😉

• Eberhard Huber wertet seine Umfrage weiter aus und philosophiert über das Wasserfallmodell und agile Vorgehensweisen.
• Ron Rosenhead setzt sich mit project creep – also dem fließenden Ändern der Projektanforderungen auseinander, und das ist eine „Projektkrankheit“ unter der wir alle leiden.
• Marcus Raitner beschäftigt sich mit dem Thema Messbarkeit.
• Brad Egland denkt über Soft Skills für Projektmanager nach.
• Schätzungen – egal ob in SCRUM (oder anderen agilen Methoden) oder klassisch ist immer etwas magisch. Boris Gloger rezensiert einen Artikel von David Campey.
• Glen B. Alleman, hat ein sehr technokrarische Projektverständnis und echauffiert sich über den „Lazy Pojektmanager“.
  Der „Lazy Project Manager“ beruht im Wesentlichen auf dem Pareto Prinzip (also der Konzentration auf dem Wesentlichen) und einer realistischen Vorstellung der sogenannten Work-Life-Balance. Die Lektüre des „LPM“ habe ich ehrlicherweise abgebrochen, nicht weil ich ihr widersprechen würde, sondern eher weil sie mich wegen mangelndem Neuigkeitswert gelangweilt hat und für so wenig neue Inhalte etwas marktschreierisch aufwartet.