Im vorherigen Beitrag ging es um die Frage, ob wir überhaupt Ziele brauchen. Die Antwort war differenziert: Nicht jede Situation verlangt nach einem präzise formulierten Ergebnisziel. Aber Handlungsfähigkeit braucht bewusste Orientierung.

Doch auch ein sinnvolles und klar formuliertes Ziel steuert unser Handeln nicht automatisch. Es kann im Strategiepapier stehen, in einem Workshop beschlossen oder im persönlichen Notizbuch festgehalten sein – und trotzdem im Alltag wirkungslos bleiben.

Denn Ziele zu setzen ist nur der Anfang.

Wenn Ziele leere Hüllen bleiben

Ziele können existieren, ohne unser gegenwärtiges Handeln tatsächlich zu steuern.

Ein formuliertes Ziel ist zunächst nur eine leere Hülle: eine Beschreibung dessen, was einmal sein soll. Mit Leben gefüllt wird diese Hülle erst durch die Bedeutung, die wir dem Ziel geben, durch unsere Bindung daran und durch die Handlungen, mit denen wir es verfolgen.

Die Forschung zur Lücke zwischen Absicht und Verhalten stützt diese Unterscheidung. Paschal Sheeran zeigte in einer Metaanalyse, dass selbst erklärte Absichten nur einen Teil des späteren Verhaltens erklären. Menschen können also durchaus wissen und benennen, was sie erreichen wollen, ohne entsprechend zu handeln. Die Formulierung eines Ziels ist noch keine Garantie für seine Umsetzung.

Ein Ziel, zu dem sich niemand verpflichtet fühlt, bleibt eine Absichtserklärung. Ein Ziel, das aus der Aufmerksamkeit verschwindet, verliert seine steuernde Wirkung. Ein Ziel ohne konkrete Handlung bleibt ein Wunsch. Und ein Ziel, das nicht überprüft wird, kann zur starren Vorgabe werden.

Zielsetzung ist ein Ereignis. Zielarbeit ist ein Prozess.

Das gilt für persönliche Ziele ebenso wie für Organisationen. Unternehmen entwickeln Strategien, vereinbaren Jahresziele und veranstalten aufwendige Workshops. Projekte formulieren Zielsetzungen und erwartete Ergebnisse. Doch nach der Zielsetzung beginnt der Alltag. Neue Anforderungen entstehen, operative Probleme verlangen Aufmerksamkeit und andere Themen erscheinen dringlicher.

Die entscheidende Frage lautet deshalb nicht nur, ob ein Ziel formuliert wurde. Entscheidend ist, was zwischen einem Wunsch, einer Zielentscheidung und ihrer Umsetzung geschieht. Wann wird aus einer erwogenen Möglichkeit ein Ziel, an das wir uns tatsächlich gebunden fühlen? Und wie verändert diese Entscheidung die Art, in der wir denken und handeln?

Genau an diesem Übergang setzt das Rubikon-Modell an.

Vom Abwägen zum Handeln: das Rubikon-Modell

Heinz Heckhausen und Peter Gollwitzer unterscheiden im Rubikon-Modell verschiedene Phasen zielgerichteten Handelns. Das Modell beschreibt damit nicht lediglich eine zeitliche Abfolge. Es zeigt, dass vor und nach einer Zielentscheidung unterschiedliche psychologische Aufgaben zu bewältigen sind.

Ich hatte gerade einen interessanten Dialog mit der KI (ChatGPT). Die alte Ausgabe des PMBOK (V. 7 ) habe ich hier schon besprochen. Damit verbunden war eine klare Kontextorientierung, die bisherige Prozessorientierung wurde nicht aufgegeben, aber wanderte in die Anhänge.

Mit der 8. Version kommt ein verzweifelter Rollback.

Aber zu meinem Dialog mit der KI:

ICH: Böse interpretiert würde ich das als ein feiges Zurückrudern einordnen. Die theoretisch/generische Prozessorientierung kommt zurück in den Fokus und weicht den kontextspezifischen Ansatz aus der Vorversion auf. Wie siehst du das?

ChatGPT: Okay. Deine Lesart ist gut begründbar. Ich würde sie nur etwas präzisieren: PMBOK 8 ist weniger ein vollständiges Zurückrudern als ein politisch und kommerziell motivierter Kompromiss, der den konzeptionellen Mut von PMBOK 7 deutlich abschwächt.
PMBOK 7 hatte eine starke, wenn auch unbequeme Botschaft:
Professionelles Projektmanagement lässt sich nicht durch einen universellen Katalog von Prozessen beschreiben. Es muss aus Prinzipien, Kontext, gewünschter Wirkung und situativen Entscheidungen heraus gestaltet werden.
[…]

ICH: Also weil die Zielgruppe zu „blöd“ ist ein zurückrudern, um mehr Akzeptanz zu finden?

ChatGPT: Okay. Zugespitzt: Ja – PMI traut seiner eigenen Zielgruppe offenbar nicht zu, mit einem konsequent kontextorientierten Standard produktiv zu arbeiten. „Zu blöd“ trifft es trotzdem nicht ganz.
Das Problem liegt auf drei Ebenen:

Das PMI-Geschäftsmodell braucht vermittelbare Inhalte.
Zertifizierungsprüfungen, Schulungen und Lehrmaterial funktionieren besser mit benennbaren Domains, Prozessen und Zuordnungen als mit situativer Urteilskompetenz. Kontextkompetenz lässt sich schlechter standardisieren und prüfen.

Viele Anwender wollen Eindeutigkeit.
Prinzipien und Kontextentscheidungen verlangen Urteilskraft. Prozessmodelle liefern scheinbar klare Antworten: Was kommt wann, wer macht es, welches Artefakt entsteht? Das vermittelt Sicherheit, selbst wenn sie fachlich trügerisch ist.

Organisationen wollen Standardisierung.
PMOs, Beratungen und große Unternehmen brauchen Prozesse, Rollenmodelle, Templates, Audits und Toolkonfigurationen. Ein Standard, der im Kern sagt „Es kommt darauf an“, lässt sich schwer operationalisieren und kontrollieren.

[…]

PMI reagiert darauf, dass ein erheblicher Teil seines Marktes verbindliche Orientierung mit konkreten Prozessen verwechselt – und bedient dieses Bedürfnis, statt die notwendige Kontext- und Urteilskompetenz weiterzuentwickeln.

[…]

Noch schärfer formuliert: Nicht die Zielgruppe ist zu blöd. PMI behandelt sie wie eine Zielgruppe, der man keine anspruchsvolle professionelle Urteilsbildung zumuten kann – möglicherweise, weil sich regelorientierte Sicherheit besser verkauft als reflektierte Unsicherheit.

P.S. noch als kleiner Anhang, die Gegenüberstellung von V. 7 und V. 8

Inhaltliche Verschiebung

Und es geht weiter in der Reihe „Projekte – Spielend erfolgreich“.

Beim Thema Visualisierung stellen sich die folgenden Fragen:

• Wie kann uns Visualisierung helfen?
• Was ist der Picture Superiority Effekt?
• Wie funktionieren Anker und Anknüpfungspunkte?
• Was ist visuelle Sprache?
• Was ist Business Visualisierung?
• Wie sieht der Prozess des visuellen Denkens aus?

Und hier geht es zur vorherigen Folge und hier zur nächsten Folge.

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.

Design Thinking hat einige wenige ganz zentrale Elemente auf die wir zum Teil später noch näher eingehen werden:

• Design Prozess
• Interdisziplinarität
• Raum

Und bei ideo werden explizit auch noch Werte angeführt.

Gleich zum Start dieser kleinen Serie eine kleine Übersicht von Design-Prozessen:

Den Anfang machen die prominenten Vertreter des Design Thinking: Das  Modell des Hasso-Plattner-Instituts (HPI) und die Prozessdarstellung der ideo. Während die ersten drei Schritte beim HPI, bzw. die ersten beiden bei ideo im wesentlichen einer Orientierung entsprechen (der Projektmanager würde vielleicht von Auftragsklärung sprechen), widmen sich die letzten drei Schritte dem kreativen Prozess von der Ideengenerierung über die experimentelle Prototypenentwicklung bis hin zur evolutorischen Weiterentwicklung der Ideen/Prototypen.

In der Darstellung vernachlässigt sind zunächst mögliche Sprünge im Design Prozesses, sprich: Es handelt sich keinesfalls um ein Wasserfallmodell, das sequentiell durchlaufen wird. Der Prozess erlaubt vielmehr nahezu beliebige Sprünge zwischen den Prozessschritten. Dies ist Gegenstand der nächsten Folge dieser kleinen Serie.

Den Prozessvarianten der beiden Platzhirsche sei bewusst noch eine weitere Variante eines Design Prozesses gegenübergestellt: Der Design Prozess nach Bella Martin und Bruce Hanington. Die Prozesse  á la HPI und ideo finden sich quasi im Kern dieses Prozesses. Vorangestellt wird aber so etwas „profanes“ wie eine Planung und für den Erfolg einer Entwicklung wahrscheinlich noch entscheidend: Der nachgelagerte Schritt der Markteinführung. Auch Design-Prozesse sind schließlich kein Selbstzweck.

Design Prozesse sind kein Vorgehensmodell für Projekte, sondern eine „Problemlösungsmethodik“ aus dem Kreativbereich, die wir selbstverständlich auch in Projekten anwenden können. Wenn wir hier Design Thinking mit Projektmanagement-Methodiken vergleichen, dann nur um daraus zu lernen und die Welt des Projektmanagement zu reflektieren.

Quellen:

• http://www.hpi.uni-potsdam.de/d_school/designthinking
  
• http://www.gruenderszene.de/lexikon/begriffe/design-thinking
• Bella Martin, Bruce Hanington, Designmethoden – 100 Recherchemethoden und Analysetechniken für erfolgreiche Gestaltung, München 2013 (Amazon)

Auf openPM habe ich gerade eine neue Diskussion ins Leben gerufen, die versucht den Projektbegriff zu schärfen.

Ist es nicht so, dass der Projektbegriff immer inflationärer gebraucht wird und eine „Projekttitis“ um sich greift? Der größte Schwachsinn wird als Projekt betrieben, aber „echte“ Projekte werden als U-Boot gefahren?

Aber jenseits aller Polemik: Wenn man Projekten von Prozessen (und Prozesse sind ganz sicher kein Schwachsinn) abgrenzt, dann stellt sich die Frage nach der Einmaligkeit des Unterfangens. Oder die Frage, ob es sich eher um eine Optimierungs- oder eine Problemlösungsaufgabenstellung handelt. Und um gleich ein neues Fass aufzumachen: Vernachlässigen agile Ansätze mit ihren iterativen Annäherungen nicht mitunter komplexe mitunter auch sequentielle Zusammenhänge?

Bitte mitdiskutieren auf openPM!

Mit zahlreichen Fußballanalogien und -weisheiten führt uns Alexander Ockl durch ein Praxisbeispiel der Geschäftprozessgestaltung zwischen IT und Fachbereich (Amazon). Er wählt dabei eine Romanform, wie man sie z.B. von DeMarco´s PM-Klassiker „Der Termin“ (Amazon) kennt. Neben dem Praxisbeispiel zieht sich die Geschichte eines Revierderbys (Achtung, Fußball!), wie ein roter Faden durch das Buch.

Die anfängliche Projektkrise und die auftauchenden Konflikte werden seziert. Alexander Ockl führt dabei in die Welt der Business Analyse und Geschäftsprozessmodelierung ein. Es wird der Bogen gespannt von Requirements Engineering, ARIS-Modellierung bis hin zu Projektmanagement-Methoden, Qualitätsmanagement und Reifegradmodellen.

Eine gelungene Einführung, die sich angenehm leicht liest, sofern man von der Überdosis Fußball nicht abgeschreckt wird.

Und indirekt liefert Ockl auch einen interessanten Beitrag zum Thema Projekterfolg/Scheitern von Projekten: Das ursprünglich initiierte Projekt scheitert grandios. Das Buch schildert dennoch eine Success Story, denn durch die erfolgreiche Analyse werden viel tiefergehende Veränderungen angestossen, aber hier wird Ockl übertrieben optimistisch:

Es ist gar nicht selbstverständliche, dass die tatsächlichen Probleme so klar identifiziert und auch angenommen werden. Zu guter letzt macht ein Bereichsleiter auch noch Karriere und wird zusätzlich Qualitätsbeauftragter. Das ist für Ockl eine Art Ritterschlag. Der Firmenchef träumt obendrein davon Qualitätsmanagement als Führungsinstrument zu nutzen. Hier verliert mich Ockl komplett. Eine solche Welt besteht wohl vor allem im Wunschdenken von Business Process Management-Anhängern.

Alexander Ockl
Das Spiel. Brennpunkt Geschäftsprozesse – IT und Betrieb in einer Mannschaft. Projektmanagement, Business Analyse und Geschäftsprozessmanagement in der Praxis
München 2010
Addison-Wesley
ISBN 978-3827329066