Leider ist der Titel etwas beliebig, aber damit ist auch schon alles Negative, was man über diese Buch sagen könnte, erschöpft, denn Berta C. Schreckeneders Buch ist eines der besten Projektmanagement-Bücher, die ich bislang in Händen gehalten habe.
Ihr gelingt ganz ausgezeichnet der Spagat zwischen Praxis-relevant, wissenschaftlich fundiert und praktischen Methodenhilfen. Andere Bücher beschränken sich meist auf eines dieser Felder, umso bemerkenswerter ist „Projektführung für Profis“ (Amazon). Es werden drei ganz zentrale Themenkomplexe aufgegriffen, die aus Sicht einer Führungskraft reflektiert werden:

1. Das Spannungsfeld zwischen Projekt und Linie
2. Erfolgreich und gesund (herbei geht es v.a. um meine Lieblingsthemen: Erfolg und Scheitern – des Projektes und der eigenen Person)
3. Kultur und Kompetenz (Sprich: Projektkultur – für viele leider immer noch ein Fremdwort)

In einem vierten Abschnitt, dem Handbuch, werden die Methoden, Übungen und Lernfelder aus den vorangegangenen Kapiteln noch einmal – sozusagen als Nachschlagewert und Arbeitsvorlage – zusammengefasst.

Mit diesen praktischen Übungen, eingebettet in einen fundierten Hintergrund liefert Berta C. Schreckeneder gleichzeitig auch eine der besten Vorlagen zum Thema Projektcoaching, die durchaus auch zu einem Selbstcoaching geeignet sind.

Eine ganz klare Leseempfehlung für Führungskräfte und Projektarbeiter!

Es mag sich schizophren anhören, wenn ich diese Frage stelle, obwohl ich von der ersten Stunde an bei openPM dabei bin, aber um ehrlich zu sein: Ich stelle mir die Frage immer wieder und erstaunlicherweise ändern sich auch die Antworten.

PM-Wiki, Projektmanagement-Werkzeugkasten

Ausgehend von der Kritik an den Verbänden und Standards, war das wohl so eine Art Ausgangsposition. Marcus Raitner meinte damals salopp: „Das können wir auch!“, aber was wir können, wussten wir wohl selbst nicht. Symbolisch für diese Antwort steht die Lego Serious Play Session vom PM-Camp 2011 in Dornbirn:

Ein Wiki ist nicht gleich Wiki

Bei Wiki denkt man schnell an Wikipedia und unser alle Vorstellungen von Wikis sind davon stark geprägt. Beim Aufbau der openPM-Plattform mussten wir dann aber schnell feststellen, dass dem so nicht ist. Während bei Wikipedia alle Beiträge flach (nicht hierarisch) auf einer Ebene liegen, wurde von vielen Seiten der Wunsch an uns getragen, das PM-Know How – der besseren Übersicht wegen – zu strukturieren. Aber nach welcher Struktur? Nicht dass es an Struktur gemangelt hätte  – eher im Gegenteil: Zu viele konkurrierende Strukturen – GPM, PMI, Prince2, agile Ansätze,… Unser Ausweg war ein fauler Kompromiss: Wir beschlossen mit verschiedenen Sichten auf den gleichen Content zu arbeiten. Und die Struktur auf unserer Confluence-Plattform ergab sich auch noch aus redaktionellen Überlegungen: Zum einen haben wir versucht den Einstiegspunkt in die Sichten zu verankern, zum Anderen sollten dort auch zentrale Listen, wie unser Meta-Glossar, die Literatur– oder die Softwareliste gefunden werden.

Hort für Listen

So wurde openPM erst mal zu einem Hort für Listen, auch aus der Überlegung heraus, dass wir so schon zu einem sehr frühen Zeitpunkt, noch bevor mehr eigener Content zur Verfügung stand PM-Wissen umfassend bedienen konnten. Eigene Inhalte wurden parallel gesät und unser Kernteam war in einer Gärtnerrolle, diese voranzutreiben. Dabei merkten wir, dass schnell etwas Neues entstand:  Eine Community

Community

Die Community ist ein Punkt in dem sich openPM ganz gravierend von einem Wiki wie Wikipedia unterscheidet: Die Nutzer und Autoren der Wikipedia sind viel zu heterogen, als dass sie als eine Community gesehen werden können. Mit unserer Fokussierung auf das Thema Projekte ist dies anders. Es gibt mehr Gemeinsamkeiten und gemeinsame Interessen und das ganz unabhängig von den verschiedenen Schulen und Ansätzen. Im Unterschied zu Wikipedia kristallisierte sich immer mehr heraus, dass wir keinen rein lexikalischen Ansatz fahren, sondern  das Raum sein muss für unterschiedliche „Wahrheiten“ (Pluralismus) und vor allem auch für Meinungen. Während in Wikipedia Meinung und Diskussion  dem lexikalischen Denken hintan steht, fanden schnell immer mehr spannende Diskussionen ihren Platz auf openPM. Technisch haben wir das Wiki dabei sicherlich etwas missbraucht. Da wäre ein Forum vielleicht zweckmäßiger gewesen, aber so entstanden alle Inhalte auf einer Plattform. Auf dieser Plattform findet sich neben den klassischen Wiki-Inhalten, den Listen, den Diskussionen, etc. auch Platz für verschiedene Aktionen, z.B. die Diskussion um die fiktive Organisation eines Stadtfestes, Frederic Jordans Versuch ein echtes Projekt zum Thema Ideenmanagement zu dokumentieren (bei dem es ihm so erging, wie es uns bei vielen Projekte ergeht: Es wurde eingestellt.), die gemeinsame Entwicklung von Checklisten oder des openPM-Canvas und der Dokumentation der PM-Camps.

Plattform für Projekte

Was ich für mich gelernt habe ist, dass openPM somit auch eine Plattform für Projekte ist, auf der gemeinsam (Collaboration rocks!) Experimente gestartet  und Inhalte entwickelt werden. Ich freue mich schon auf viele anstehende Themen, sei es Rainer Eschens Blue Scrum Projekt, Alexander Mereiens Ideen zum Projekt-Inszenator und vieles mehr

Vermutlich sind alle Antworten richtig. openPM kann das alles sein und natürlich ist openPM auch ein gemeinnütziger Verein, der eben u.a. die Plattform betreibt.

Wieder ein Buch bei dem es um innere Haltung geht (Amazon), um Führung und um Entscheidungen unter Unsicherheit. Olaf Hinz hat gar nicht den Anspruch ein umfassendes PM-Lehrbuch zu liefern, sondern fokussiert stark auf den Aspekt der Führung und die liegt auf unserem ollen Projektkahn, aber genauso auch bei super-modernen Projekttankern oder kleinen schicken Projekt-Jachten in der Hand des Projektkapitäns. Olaf schenkt uns ein Metaphernbuch voller Schätze an seemännischen und nicht-seemännischen Projektmetaphern.

Hier ein paar Beispiele solcher Bonmots:
• „ An Deck hat der Kapitän das Kommando, an Land der Reeder.“
• „Es gilt das ‚Ohr auf der Schiene zu haben‘ und frühzeitig zu reagieren.“
• „Politiker erhalten 100 Tage Schonfrist, wenn sie ein Amt antreten – ein Projektleiter muss sofort volle Leistung bringen.“
• „Alle Mann an Bord – Motivation und Teamarbeit dank Sinn und Zusammenhang“
• Gruppendynamik – „Denn diese ist wie das Wetter – immer da.“
• „Helden sind Getriebene“
• „Streng nach Plan geführte Projekte sind wie in die Dose gepresstes Fleisch in Form gebracht und in Struktur gepresst! (…). Dem Dosenfleisch fehlt die Würze des aktuellen Kontextes und die Kommunikation mit und aus dem Umfeld.“

Olaf durchschifft mit uns die klassischen Themen von der Auftragsklärung, der Projektkommunikation, smarten Zielen, Motivationstheorien bis hin zum Umgang mit Komplexität. Hier macht er sich insbesondere stark für ein Rückkoppelungsmodell an Stelle eines starren linearen Denkmodells. Eine Herausforderung sind hier z.B. unentscheidbare Entscheidungen:

„Hier muss die Führungskraft Mühe und Risiko des Entscheidens selbst übernehmen. Das heißt: In einer Situation, in der ein festgelegter Regelprozess nicht greift, werden Fachleute verschiedene Vorschläge entwickeln, was zu tun ist. Jeder Vorschlag leuchtet in gewisser Weise ein, der Führungskraft werden am Ende zwei oder drei durchaus plausible Alternativen. Und die Mitarbeiter werden drängen: ‘Wie machen wir es denn jetzt, Chef?‘ Und der muss dann eine unentscheidbare Entscheidung treffen. Das bedeutet, dass er unter Unsicherheit handelt und das Risiko trägt.“

Als Fazit zieht Olaf sechs Leitsätze heran, die es braucht um ein Projekt auf Kurs zu halten:
1. Variantenreiche Führung und klare Rollen verhindern Schlagseite
2. Nur wer aktiv kommuniziert, kann auch das Ruder in der Hand haben
3. Sinn und Zusammenhang, d.h. die Motivation der Besatzung bestimmt das Tempo
4. Bei wechselnden Winden an das Kreuzen denken
5. Heldentum ist tapfer aber meist nicht klug
6. …und: Projekte führen bedeutet: Es kommt immer noch was nach!

„Der Projektkapitän“ ist nicht so etwas wie ein Werkzeugkasten, sondern eher eine Denkschule, die zur Reflexion einlädt.

Olaf Hinz, Der Projektkapitän: Mit seemänischer Gelassenheit Projekte zum Erfolg führen, Wiesbaden 2013, ISBN-13: 978-3-658-01450-6
Überarbeitete und erweiterte Neuausgabe des Titels: „Sicher durch den Sturm – so halten Sie als Projektmanager den Kurs“, erschienen im Orell Füssli Verlag

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.

Ich bin noch einen ausführlichen Bericht vom PMCampRM schuldig:

PMCamps überwältigen mich immer wieder mit ihrer Intensität und dem Networking. Bei jedem Camp an dem ich bisher teilgenommen habe, war ich immer noch wenigstens die folgende Woche damit beschäftigt die Eindrücke zu verdauen, aufzubereiten und mich mit anderen Teilnehmern zu vernetzen. Das gilt auch für das diesjährige PMCampRheinMain – mein erstes regionales PMCamp, nachdem ich bislang immer in Dornbirn, bei der Mutter aller PMCamps dabei war.

Die regionale Farbe bringt ein paar Eigenheiten mit, die Abednevents verlierren beispielsweise an Bedeutung, weil doch eine größere Zahl der Teilnehmer wieder abends nach Hause fährt, auf der anderen Seite werden so auch wieder völlig neue Teilnehmerkreise erschlossen.

Besonders gefreut hat mich, dass es uns gelungen ist, die Sessiondokumentation auf openPM zu realisieren. Wer sich also für inhaltliche Details der Diskussionen interessiert kann hier gerne nachlesen.

• Persönliches Highlight war natürlich das Networking. Viele neue Kontakte und auch eine ganze Reihe alte und neue Mitstreiter für openPM.
• Ein echter Geheimtipp, den ich leider verpasst habe war Marions Session „Aufrichtigkeit„, in der sie sich mit Körpersprache auseinander gesetzt hat.
• Bei Torsten Koertings Impuls Workshop zum Project Square habe ich mich in die Beobachterrolle zurück gezogen, nachdem ich sowohl Torsten, den Project Square als auch andere Canvas-Konzepte schon länger kenne und schätze. Gemeinsam mit Torsten konnte ich insbesondere die Gruppendynamik beobachten und studieren. Wirklich auffallend wie offenbar die ideale Gruppengröße aus fünf Teilnehmern bestand und wie sich jede Gruppe völlig unaufgefordert einen Moderator gesucht hat.
• Über Jurgen Appelos Management 3.0 habe ich hier schon berichtet, es war trotzdem ein Highlight einzelne seiner Übungen wie Delegation Poker in der Gruppe zu praktizieren. Ein herzliches Dankeschön hierfür an Oliver Buhr!
• Olaf Hinz hat mit dem Thema Rolle des Auftraggebers bei mir ein paar Gedanken hervorgerufen, die sicher noch in weiteren Beiträgen münden werden.
• Völlig zu Unrecht etwas untergegangen ist Günter Webers Fokus-Chart, der sehr gut in eine Reihe mit dem Project Square und mit dem von Oliver Buhr am Rande des Project Square angeführten Bluesheets von SmartPM oder dem open PM-Canvas gepasst hätte.

Ich bitte alle in diesem kurzen Abriss nicht erwähnten Sessions um Verzeihung, ich habe teilweise die agilen Sessions etwas vernachlässigt, aber nur weil ich mich auf anderen PMCamps schon verstärkt damit auseinander gesetzt habe, zu erwähnen wären beispielsweise noch die Wissensmanagement-Session von Silvia Schacht oder Lego for Scrum mit Tilman Moser.

Fazit: Wer einmal vom PMCamp-Virus befallen ist, wird zum Wiederholungstäter, so wie ich. Nächste Chance für eine PMCamp-Teilnahme ist übrigens das PMCampBerlin im September!

Von Donnerstag bis Samstag fand das erste PMCamp RheinMain statt und aktuell entsteht auf openPM gerade die Sessiondoku. Wie bei jedem PMCamp wird die Aufbereitung und Nacharbeit noch andauern. Noch schwirren tausend Gedanken und Ideen durch den Kopf. Allein die neuen Kontakte und der Austausch haben sich schon gelohnt. Highlight war u.a. der Impuls-Workshop von Torsten Koerting, nein, Highlight sind einzig und allein die Teilnehmer. Die Interaktivität der PMCamps sind einzigartig! Es geht nicht um die Referenten, sondern um die Diskussion und die weckt selbst bei alten Hasen Neid und steckt sie an. Eine ausführliche Rezension folgt in den nächsten Tagen. (Geheimtipp, den ich dummerweise verpasst habe ist Marions Beitrag zum Thema „Aufrichtigkeit„)

Letztes Wochenende war PM Camp in Wien, dieses Wochenende ist PM Camp RheinMain. Ich bin dabei und auch kurz entschlossene Anmeldungen sind noch möglich. Ich freue mich auf ein weiteres Highlight. PM Camps sind Familientreffen und fachlicher Austausch zugleich. Ich möchte sie nicht mehr missen!

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) 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.

Gunter Dueck, Aushängeschild der Web 2.0 Gemeinde, hat sein neues Buch veröffentlicht:
Gunter Dueck, Das Neue und seine Feinde: Wie Ideen verhindert werden und wie sie sich trotzdem durchsetzen, campus, Frankfurt 2013, ISBN-13: 978-593-39717-7 (Amazon)

Diesmal beschäftigt er sich mit dem Thema Innovation, aber nicht im Sinne eines klassischen Innovationsmanagement, nein, sein Buch ist eine konsequente Management-Kritik und stellt vor allem die Psychologie und Hemmnisse in den Vordergrund. Es ist obendrein ein sehr persönliches Buch, weil es Duecks Erfahrungen auf seinem Weg bis zum CTO der IBM widerspiegelt. Ein paar mehr Referenzen und Literaturverweise hätten dem Buch aber nicht geschadet. Trotzdem: Eine spannende Lektüre von einem Autor, der (a) etwas zu sagen hat und (b) ein schelmischer Meister des Storytelling ist.

Ein zentraler Bestandteil des Buches ist Duecks Resistenzmodell in dem er aufzeigt wie sich eine Innovation über die Zeit in verschiedenen Personengruppen (Protagonisten, OpenMinds, CloseMinds und Antagonisten) durchsetzen muss um erfolgreich zu sein. Es gilt eine kritische Hürde („Chasm“) zu überwinden bis eine Innovation zum Selbstläufer wird. Während BWLer ihre Modelle gerne in Matrix-Form aufbauen, um die Welt zu erklären, verwundert es nicht, dass Dueck als Mathematiker sein Resistenzmodell auf einer Gauß-Kurve aufbaut.

😉

Dueck zeigt nüchtern die geringe Erfolgswahrscheinlichkeit von Innovationen: Demnach hat ein Startup, das von einem Erfinder aufgesetzt wird eine Erfolgswahrscheinlichlichkeit von 5%. wenn Management-Know-How und Expertise hinzukommen, steigert sich die Quote auf 11% oder zu Deutsch: 89% aller unter besten Bedingungen gestarteten Innovationen scheitern. Bei diesen Zahlen muten Erfolgsbetrachtungen aus dem Projektmanagement, wie der CHAOS-Report der Standish-Group, plötzlich als Best Practice an (was sich aber leicht erklären lässt, weil nicht jedes Projekt hochgradig innovativ ist).

Und konsequent erinnert er uns daran auf was es wirklich ankommt:

• Leidenschaft
• 100%-iges Engagement
• Unterstützung
• Meisterschaft
• Aktive und passive Prozesskompetenz
• Die Schaffung eiens geeigneten Kräftefeldes
• …

Duecks Management-Kritik gipfelt in seiner fiktiven, sarkastischen Betrachtung eines Vice-President Innovation in einem beliebigen Großunternehmen. Und dementsprechend gibt Dueck auch Tipps wie:

• Think and speak visionary, act evolutionary!
• Work underground as long as you can!
• Was du auch tust, tu es gut.

Als Gegenmodell zum klassischen Innovationsmanagement empfiehlt er eine Orientierung an der agilen Software-Entwicklung.

Und schließlich mündet Duecks Betrachtung in seinem Fazit von Innovation als Sisyphos-Arbeit:

„Innovation, die sich lohnen soll, muss als Herkulesaufgabe betrieben werden, mit voller Kraft. Innovation ist wie »Sisyphos schafft es doch.«“

Wie immer ist Dueck voller persönlicher Anekdoten und Bildern und die Lektüre lohnt sich nicht nur aufgrund seiner Qualitäten als Storyteller. Positiv übrigens auch, dass man mit Erwerb des gebundenen Buches auch das eBook erhält.

Und hier noch der Link zu Duecks Webseite: Omnisophie

Und wieder einmal geht es um Erfolg und Scheitern von Projekten, aber diesmal nicht auf Ebene des einzelnen Projekts, sondern auf der Meta-Ebene.

Den mit Abstand inspirierendsten  Impuls zum Thema habe ich in der aktuellen Session Dokumentation zum PM Camp Stuttgart gefunden: Vermutlich zurückgehend auf Eberhard Huber, wird dort der Projekterfolg nicht aus Sicht des Projekts, sondern in einer Meta-Perspektive diskutiert (Doku auf openPM):

 Viele Projekte sind ggf. nur Teilschritte eines größeren Veränderungsvorgangs (vgl. Portfoliomanagement). Möglicherweise ist in einer Sequenz von Projekten ein scheinbarer Misserfolg nötig, ggf. sind die Misserfolge nur Lernschritte auf einem größeren Weg auf dem das konkrete Projekt nur einen Teilschritt darstellt.

Die Beurteilung des Projekterfolgs erfolgt also nicht mehr auf der Ebene des einzelnen Projekts (Projektauftrag, Stakeholdererwartung, etc.), sondern im Kontext des organisatorischen Anpassungs- und Erneuerungsprozesses.

Das Scheitern vieler Projekte vor dem Hintergrund innovativer Prozesse scheint normal. Scheitern heißt lernen. Interessant scheint die Implikation auf die Business Case Betrachtung. Sind hart gerechnete Business Cases vor dem Hintergrund der hohen Rate gescheiterter Projekte überhaupt sinnvoll?

Aber trotzdem brauchen Organisationen Projekte um ihre Fähigkeit zur Selbsterneuerung und Erhaltung zu beweisen.

Wir stehen erst am Anfang einer spannenden Diskussion!