Archiv der Kategorie ‘Projektmanagement‘

 
 

#635 Zukunft des Projektmanagements

Haben wir nicht jüngst mit einer Blogparade, auf dem PM Camp in Dornbirn und auf openPM zugegebenermaßen rhetorisch (aber selbstkritisch) nach dem Beyond Project Management gefragt?

Ganz anders die aktuelle Ausgabe von projektManagement aktuell, eine Jubiläumsausgabe, die sich selbst feiert (Ehrlicher Glückwunsch zum 25. Geburtstag!) und einen Blick in die Zukunft de Projektmanagements zelebriert mit Beiträgen wie „Future Trends in Project Management“, „‚Drahtseilakt‘ für Projektmanager“ oder „Das Projekt als ‚Nukleus‘ der Strategiearbeit“.

Die Future Trends entstammen übrigens einer Befragung von „26 internationalen Akademikern und 22 Praktikern“, sie mögen völlig zutreffend sein, aber bei dieser Grundgesamtheit verkleidet mit einem wissenschaftlichen Anstrich, sollte man die Kirche vielleicht im Dorf lassen oder den Beitrag eher als Thesen, denn als handfeste Ergebnisse deklarieren. Geburtstagsfeiern sind ja schön und gut, aber selbstgefälliges Schulterklopfen muss nicht sein.

Als Future Trends werden in der Studie von Hans Georg Gemünden und Yvonne-Gabriele Schoper übrigens genannt:

  1. „Projektifizierung“ der Gesellschaft
  2. Wachsende Bewältigung von Komplexität
  3. Transantionalisierung der Projekte
  4. Virtualisierung
  5. Professionalisierung des Projektmanagements
  6. Lernen & Qualifizierung im Projektmanagement
  7. Projekte als Vehikel um Unternehmensziele zu erreichen
  8. Verbessertes Stakeholdermanagement
  9. Projektmanagement erobert die Vorstandsetagen
  10. Projektorientierte Organisation
  11. Ein zunehmender Anteil von Frauen im Projektmanagement
  12. Projektmanagementforschung wird intensiviert

Die einzelnen Trends sind natürlich nicht unabhängig voneinander (z.B. Professionalisierung und Lernen & Qualifizierung) und vielleicht auch dem Kreis der Befragten geschuldet (Forscher wollen intensiviert forschen). Die Projektifizierung (oder sollte ich sagen: „Projektitis“), der Stellenwert von Projektmanagement in den Vorstandsetagen und der Umbau von Organsiationen in Projektorientierte Organisationen vermitteln mir auch den Eindruck von Wumschdenken. So würden wir uns gerne sehen und diese Wertschätzung würden wir gerne widerfahren. Ich glaube gar nicht mal, dass die Anzahl „echter“ Projekte wirklich zugenommen hat, aber an immer mehr Aufgaben wird einfach missbräuchlich das Etikett „Projekt“ geklebt. Projekte werden (auch auf Vorstandsetagen) instrumentalisiert (z.B. in der Budgetplanung oder im Change Management) ohne Gegenstand und Vorgehensweise zu reflektieren, da wird dann mitunter sinnfrei eine Projektlogik übergestülpt. Ich fürchte, dass diese missbräuchliche Inflation nicht zwingend zu einer Professionalisierung beitragen, sondern möglicherweise vermehrt zu Akzeptanzproblemen führen wird. Aber lassen wir uns überraschen. Schau´mer mal, dann sehgn ma scho, wie der Bayer sagt.

#632 Die Mutter aller PMCamps – PMCampDOR

Zurück von der Mutter aller PM-Camps – vom PMCampDOR14 in Dornbirn.

Es war spannend, inspirierend, kreativ, voller Diskussionslust und vieler Impulse. Also halt so, wie immer!

Nachzulesen auf Twitter oder demnächst in der Sessiondoku, die jetzt langsam im Nachgang der Veranstaltung auf openPM entsteht. PM-Camps sind immer ein großes Klassentreffer und so ist mir z.B. diesmal @marcusschwemer wieder über den Weg gelaufen, den ich das letzte mal im Studium getroffen habe. Neue Gesichter gab es insbesondere aus der Region und es ist zu „befürchten“, dass die auch wieder kommen, denn die Resonanz von Roman, Alois, Rolands Schweizer Fraktion und vielen anderen war (wieder einmal) überwältigend. Aber natürlich auch ein Wiedersehen mit alten PMCamp-Veteranen:

 


Einen gewissen Sucht-Faktor kann man den PM-Camps einfach nicht abstreiten.

Meine Higlights diesmal waren die Keynotes (Danke an Gebhard Borck und Melanie Kaiser), deren Beiträge schon in der Sessiondoku verfügbar sind. Auch wenn Gebhard sich ein Spielchen gemacht hat und im Auditorium gefragt hat, ob er mit Folien, an der Tafel oder völlig frei referieren soll (die Entscheidung fiel für die Tafel, d.h. seine Folien wurden eigentlich nicht gezeigt), außerdem hat er sich noch ein bisschen Improvisationstheater eingebaut und alle Zuhörer für das Feedback mit roten Clownsnasen ausgestattet. Ein persönliches Erfolgserlebnis war auch, dass ich langsam dann doch einmal die Barcamp-Prinzipien verinnerlicht habe und mich langsam zu einer „Hummel“ entwickelt habe. (Ein „Schmetterling“ ist einfach nicht die richtige Metapher für mich.)

Von den Sessions möchte ich keine wirklich hervorheben, nicht weil es an Qualität gemangelt hätte, sondern weil es wieder die gewohnte Dichte intensiver Impulse gab. Die Gespräche, nicht nur in den Sessions, sondern auch am Rand sind einfach das Besondere am Camp. Ein weiteres Highlight ist immer schon der Check-In am Vorabend, der immer wieder mit großem Hallo beim Bier endet, ganz zu Schweigen von der Party am Freitag mit einem herausragenden Host Stefan Hagen, von der ich mich erkältungsbedingt allerdings etwas frühzeitig verabschiedet habe (für das Whisky-Tasting hat es aber doch noch gereicht).

Persönliches Fazit: Ich komme wieder!

#625 Was tun wenn´s brennt?

Für die zweite Ausgabe des ProjektSMag hat Tim Dettmer u.a. mich gefragt, was ich tun würde wenn ein Risiko mit hoher Tragweite eintritt. Hier meine Antwort:

  • (1) Orientieren – Meine „Lieblingswerkzeuge sind hierbei der MindManager und visuelle Hilfsmittel wie der openPM-Canvas (den ich auch selber mitentwickelt habe).
  • (2) Kommunizieren & Transparenz – Kommunikation ist der Erfolgsfaktor in Projekten schlechthin. Ohne Kommunikation gibt es keine Transparenz. Die Kommunikation muss dabei konstruktiv, also lösungsorientiert sein. Schuldzuweisungen, Fingerpointing, etc. sind gerade in Krisenzeiten zwar beliebt, aber kontraproduktiv
  • (3) Verbindliches Handeln – Ich brauche nicht die x-te Revision eines Projektplans, oft reicht schon eine einfache Aufgabenliste mit klaren Verantwortlichkeiten, die dann aber auch verbindlich umgesetzt und verfolgt wird.

#624 Gelesen: Projektmanagement im Verlag

Holger Zimmermann, Projektmanagement im Verlag, Berlin, Boston 2014, ISBN 978-3-11-032377-1 (Amazon Affiliate Link)

Wie Douglas Adams Leser wissen, hat sich der Hitchhiker gegenüber der Encyclopedia Galactica im Wesentlichen durchgesetzt, weil auf seinem Umschlag in großen, freundlichen Buchstaben steht: DON`T PANIC! Wenn mich jemand fragt, worin sich „Projektmanagement im Verlag“ von anderen guten Projektmanagement-Einführungen unterscheidet, dann würde ich ganz im Sinne Adams antworten: Mit seinem Verweis auf openPM!

Ist ja auch kein Wunder – Holger ist eines unserer Gründungsmitglieder bei openPM und sein Buch ist eine sehr solide Einführung in „klassisches“ Projektmanagement. Den zweiten Teil des Titels „…im Verlag“ kann man getrost streichen. Was inhaltlich beschrieben wird, ist vollkommen branchenunabhängig, lediglich die Beispiele und einzelne Randbemerkungen entstammen der Verlagswelt („Neue Buchreihe mit Webportal“), das ist aber keine Schwäche, ganz im Gegenteil. Umfang und Detaillierung sind vollkommen angemessen. Es handelt sich nicht um ein allumfassendes Nachschlagewerk, sondern um eine verständliche Einführung. Der Lernende wird nicht mit schierer Masse erschlagen, sondern intelligent mit vielen wegweisenden und mitunter auch relativierenden Hinweisen durch die Materie geführt.

Sehr gut gefallen haben mir die 32 Fragen, die durch das Buch (und durch Projekte) führen. Weiter gefallen haben mir die Abgrenzungen zwischen Routineprozess und Projekt, die Nutzung von Routineprozessen in Projekten (z.B. bei der Buchhaltung) und die Verantwortung in Projekten und in Routineprozessen.

Ein bisschen scheint mir das Buch technisch orientiert und etwas planungslastig, auch wenn ein nochmaliger Blick ins Inhaltsverzeichnis eigentlich eine ausgewogene Mischung zeigt. Aber keine Angst – Holger kennt sehr wohl die Grenzen der Planung, Es finden sich zahlreiche kluge Hinweise, die Einsatz und Zweck relativieren:

„Projektplanung ist nicht mehr und nicht weniger als gemeinsames, systematisches Nachdenken darüber, wie die Projektziele erreicht werden könnten.“

Dem würde auch kein Verfechter eines agilen Projektmanagement widersprechen, der eine solche Planung halt nur auf den nächsten Sprint beschränken würde.

„Sinn eines Projektplans ist nicht die Einhaltung des Plans. Ein Plan ist ein Hilfsmittel, […]“

Es geht um eine pragmatische Planung. es geht nicht um Vorgaben sondern und Abstimmungsprozesse. Planung ist auch nicht elitär, sondern sollte alle einbeziehen („gemeinsames Nachdenken“).

Das Buch folgt dem Projektablauf, von der Auftragsklärung inkl. Risiken und Projektzielen, Projektplanung, Projektsteuerung bis zum Projektabschluss. Etwas unglücklich finde ich dabei, dass einige Themen, wie Rollen, Stakeholder oder die Projektkommunikation die durchgehend relevant sind, dabei erst im Kapitel Projektsteuerung erläutert werden. Das führt bei mir wahrscheinlich zu diesem falschen Eindruck der Überbetonung von Planung. Einem PM-Anfänger würde ich auf jeden Fall als weitere Lektüre beispielsweise Projektführung für Profis (Amazon Affiliate Link) von Berta Schreckeneder ans Herz legen. Dort werden genau die anderen Facetten abgedeckt. (Und für den Spaß natürlich Tom De Marcos „Der Termin(Amazon Affiliate Link)).

Das Buch enthält einige (Formular-)Vorlagen, die QR-Codes führen dann aber in einen Webshop, in dem diese käuflich erworben werden können.

Im letzten Kapitel vor dem Schlusswort skizziert Holger noch wie ein Projektmanagement-Standard in ein Unternehmen (Verlag) eingeführt werden könnte, von der Definition eines Projektmanagement-Prozesses, der Qualifizierung der Mitarbeiter bis hin zu Pilotprojekten.

Agiles Projektmanagement spielt in dieser Einführung kein große Rolle, wenn gleich Holger treffend deren Qualitätsorientierung durch die Fokussierung auf funktionsfähige Resultate beschreibt, aber agil ist halt noch viel mehr, auch wenn die damit verbundene Grundsatzdebatte das einen PM-Newbie vielleicht an dieser Stelle nur abschrecken würde.

#622 Ein Logo für den visualPM

Martin Hausmanns UZMO ist schuld! Jetzt hat auch der visualPM sein eigenes Logo. Entstanden aus dem Spiel mit Stift und grafischen Elementen:

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

#612 Erklärvideo zum openPM-Canvas

Nachdem ich den openPM-Canvas initiiert und mitentwickelt habe, habe ich mich nun an einem Erklärvideo für den Canvas versucht.

Hinter dem openPM-Canvas verbirgt sich die Idee anhand eines vorgegebenen Rasters auf einer „Leinwand“ in grafisch, visueller Form ein Projekt samt seiner Besonderheiten und Restriktionen darzustellen. Es handelt sich dabei um eine Art Mischung aus Strukturierung, Visualisierung & Storytelling.

Der openPM-Canvas steht unter Creative Commons-Lizenz jedem zur Nutzung/Weiterentwicklung auf openPM zur Verfügung: https://www.openpm.info/display/openPM/Canvas

#611 visualPM: Design Thinking mit dem Innovation-Kanban

In dieser kleinen Reihe über Design Thinking haben wir uns bislang mit den Kernelementen und Grundlagen auseinander gesetzt, aber wie kann ich diese in meiner eigenen Arbeit umsetzen?

Meine persönliche Antwort hierauf ist der Innovation-Kanban.

Als Basis verwende ich eine Mischung aus den Design Prozessen von HPI und Martin/Hanington: Der HPI-Prozess wird noch um Planung und Umsetzung/Markteinführung ergänzt

Ausgangspunkt des Innovation-Kanban ist die Problemstellung, wie man in Innovationsprozessen, bzw. im Design Thinking Prozess den Überblick über die verschiedenen Ideen/Prototypen/Releases behalten kann, also sowohl über parallele Projekte/Vorhaben als auch über Lösungsvarianten.

Während ich für Planung & Orientierung meistens MindMaps einsetze, versuche ich den  Kern des Design Thinking-Prozesses in einer KANBAN-Tafel abzubilden.

Kanban (Wikipedia) ist ursprünglich eine Methode zur Produktionsprozesssteuerung nach dem Pull-Prinzip. In einem vorgegebenen Prozess kommt es zur Selbststeuerung. Eine  Kanban-Karte ist der Informationsträger aufgrund dessen die Prozessbeteiligten wissen, was sie zu tun haben. Visuell lässt sich dies an einem KANBAN -Board darstellen. Im Innovation-Kanban repräsentiert jede Kanban-Karte eine Idee, einen Prototypen oder ein Release und wandert auf dem Board durch die Prozessschritte. Die Platzierung der Karte auf dem Board spiegelt die aktuelle Bearbeitungsposition im Prozess.

Zur Zeit experimentiere ich noch etwas mit dem Format zwischen A0-Plot und A3-Ausdruck. Als Kanban-Karten kommen Stattys zum Einsatz, weil man die so schön „Verschieben“ kann. Da kommt dann zur visuellen Komponente auch noch das Haptische hinzu.

Im Hintergrund gibt es je Protoyp eine eigene Spezifikation/Dokumentation, in der die Konfiguration, aber auch die jeweiligen Testergebnisse festgehalten werden.

Außerdem experimentiere ich noch mit einem Innovation-Repository, einer flachen Tabelle mit einem Eintrag je Kanban-Karte mit mehreren Attribut- und Bewertungsspalten. Diese dienen dazu verschiedene Ausprägungen miteinander inhaltlich (Attribute) und bewertungstechnisch (welche Alternative ist zu bevorzugen?) vergleichen zu können. Hier kann der Excel-Freak nach Belieben Filtern und Sortieren…

Und hiermit endet die Design Thinking Serie. Es ist zwar bestimmt nicht der letzte Beitrag zu Design Thinking auf schlossBlog. Und auch der visualPM wird sich hier weiterhin zu Wort melden, aber dieser erste Überblick aus der Perspektive eines Projektmanagers ist hiermit abgeschlossen.

Bisher erschienen sind:

Der visualPM und Design Thinking – Der Design-Prozess – „Sprünge“ im Design Thinking Prozess – klassisch, agil Design ThinkingDesign Thinking – Mehr als nur ein Prozess – Design Thinking mit dem Innovation-Kanban

#610 visualPM: Design Thinking – Mehr als nur ein Prozess

Wesentliche weitere Bestandteile des Design Thinking (neben dem Prozess) sind vor allem die Interdisziplinarität und der Raum.

Interdisziplinarität ist uns in der Projektwelt nur allzu geläufig, deswegen wollen wir hier gar nicht näher darauf eingehen. In einem komplexen Umfeld sind einfach vielfältige Skills, Methoden und Perspektiven erforderlich um erfolgreiche Projektarbeit zu leisten.

Hinter dem Raum verbirgt sich nicht nur der physische Ort an dem unser Projekt stattfindet, sondern auch die visuellen (auch haptischen und andere) Komponenten. (Wie könnte der visualPM das vergessen!). Hier dürfen wir Kreativitätstechniken einsetzen, experimentieren, Prototypen entwickeln, mit Lego spielen,… Einfach kreativ sein. Pinwände, Flipcharts, Boards, Modelle,… alles gehört dazu. Allerdings sollte uns der Raum als Gestaltungsspielraum, gerade in Zeiten virtueller Projekte und verteilter Projektteams, auch ein bisschen zur Besinnung bringen. Nicht alles, was geht, ist auch sinnvoll. Face-to-Face-Kommunikation ist unheimlich wertvoll und kraftvoll. Nichtsdestotrotz erlauben uns virtuelle Konzepte auch die Zusammenarbeit mit Experten, die wir sonst nicht in unser Team einbinden könnten, aber da sind wir schon wieder bei der Interdisziplinarität…

Bei ideo werden explizit auch noch die Werte als elementarere Bestandteil des Design Thinking  angeführt. Ich bin allerdings kein Freund der Verquickung von Werten und Methoden, weil uns das im Projektmanagement beispielsweise auch die Kluft zwischen klassisch und agil zementiert hat. Mein geschätzter Kollege und Mitstreiter Eberhard Huber würde jetzt einwerfen, dass man nicht wertfrei handeln kann. Damit hat er selbstverständlich auch Recht (so wie man auch nicht Nicht-Kommunizieren kann). Meine Kritik an der Verknüpfung von Werten und Methoden bezieht sich vor allem auf eine Ideologisierung, die meist kontraproduktiv und missverständlich ist. Auch ein klassischer PM kann ein humanistisches Weltbild haben und hinter den Werten des agilen Manifests stehen. Leider haben wir schon allzu viele Diskussionen erlebt, wo diese Logik umgedreht wurde: Du bist nicht agil, also lehnst du diese Werte ab.

Was bei ideo bzgl. Werten angeführt wird, geht aber gar nicht soweit ins Ideologische. Es handelt sich eher um „Brainstorming-Regeln“:

• Arbeite visuell (be visual)

• Nur einer spricht (one conversation at a time)

• Fördere verrückte Ideen (encourage wild ideas)

• Stelle Kritik zurück (defer judgement)

• Quantität ist wichtig (go for quantity)

• Bleib beim Thema (stay on topic)

• Baue auf den Ideen anderer auf (build on the ideas of others)



bernhardschloss.de