#628 Die andere Barcamp-Doku – Streamcamp

Hier hatte ich ja schon auf das Streamcamp 2014 hingewiesen. Und wie es sich bei Streaming-Spezialisten nicht anders gehört, haben die Kollegen ihr Barcamp gleich als mit Vieostreams dokumentiert, nachzuschauen bei Hannes Schleeh:

http://schleeh.de/streamcamp-2014-hands-on-workshop-fuer-streaming/

 

#627 Kreativität und Kreativitätstechniken

Gerade eben habe ich eine Generalüberholung des openPM-Artikels Kreativität & Kreativitätstechniken abgeschlossen. Aber was heißt abgeschlossen, eigentlich ist dies erst der Anfang:

Die Übersicht der Kreativitätsmethoden lässt sich sicher noch erweitern, um Links zu Methodenbeschreibungen ergänzen und das eine oder andere Kreuz in der Beschreibungsmatrix sollte vielleicht noch korrigiert werden.

Beim weiteren Ausbau bin ich aber hoffentlich nicht allein, sondern wünsche mir möglichst viele Mitstreiter! Also wer Lust hat ist herzlich eingeladen den Artikel  (oder auch einen anderen Artikel auf openPM) zu erweitern oder zu ergänzen. Es reicht schon, wenn ihr einen interessanten Link ergänzt, einen Tippfehler verbessert, oder,  oder…

Und neue Artikel sind selbstverständlich auch erlaubt!

#626 Reporting, BI & Big Data

Reporting ist ein Klassiker.
BI (Business Intelligence) und Big Data sind allgegenwärtige Buzz Words.
Zeit sich hier einmal dem Thema zu widmen und das nicht nur für Projektmanager.

Möglichkeiten und Grenzen von Big Data

Ein Beispiel für die Nutzung von Big Data ist der Fall des Autobahn-Snipers: Ein frustrierter LKW-Fahrer schießt während der Fahrt über mehrere Jahre aus seiner Fahrzeugkabine auf andere Fahrzeuge. Überführt wird er letztlich über eine systematische Auswertung von Kennzeichen-Erfassungen auf deutschen Autobahnen. Der Aufwand dafür beträchtlich, sowohl in finanzieller als auch in zeitlicher Hinsicht.
Nicht nur im Zusammenhang mit dem NSA-Skandal wird die Aussagekraft von Kommumikations-Metadaten immer wieder thematisiert. Dimitri Tokmetzis zeigt auf netzpolitik.org, was allein schon Metadaten über uns aussagen.
Oder haben Sie sich schon einmal gewundert, was soziale Netzwerke bereits über uns wissen ohne, dass wir es ihnen gesagt haben (z.B. weil unsere Kontakte uns in ihrem Adressbuch führen oder es ungewöhnliche Schnittmengen in den Kontakten unserer Kontakte gibt).
Big Data per se ist weder gut noch böse. Die Möglichkeiten sind einerseits beeindruckend aber andrerseits auch beängstigend. Wir können uns nicht davor verschließen, aber um so wichtiger ist eine kritische Auseinandersetzung mit dem Thema. Wir haben in der digitalen Welt bereits einen Kontrollverlust über unsere Daten erlitten .(Diese Tage erscheint hierzu das Buch: Das neue Spiel von Michael Seemann – siehe auch sein Blog ctrl-Verlust.) Wer argumentiert, er hätte nichts zu verbergen, ist naiv, denn aus der Kombination an sich “harmloser” Daten entsteht mitunter eine kritische Information. Stellen Sie doch einmal einen Kreditantrag oder unterziehen sich der Gesundheitsprüfung für den Abschluss einer Versicherung und Sie sind schneller in Erklärungsnöten, als Sie sich vorstellen können.

Garbage in – Garbage out

Worüber auch Big Data nicht hinwegtäuschen kann sind die elementaren Grundprinzipien der Datenverarbeitung. Nach wie vor gilt Garbage in – Garbage out. Nur in der Flut der Daten vergessen wir manchmal welches Datum tatsächlich ein Information enthält und welches nicht oder überbewerten oder missinterpretieren dessen Informationsgehalt. Wir können unser Reporting und unsere Prozesse beliebig optimieren, aber wenn der Inhalt nicht stimmt…

Nicht Äpfel mit Birnen vergleichen

Natürlich dürfen wir auch nicht Äpfel mit Birnen vergleichen (inhaltlich).
Und zeitliche Synchronität wäre für die Vergleichbarkeit auch schön.

Korrelationen nicht mit Kausalität verwechseln

Bei der Interpretation von Daten dürfen wir selbstverständlich auch nicht Korrelationen mit Kausalitäten verwechseln. Handelt es sich tatsächlich um Ursache-Wirkungsbeziehungen oder möglicherweise nur um 2 Symptome der gleichen Krankheit…

Unwort: Komplexitätsreduktion

Es ist i.d.R. eine irrige Annahme, dass sich Komplexität reduzieren lässt. Eine Reduktion hilft uns vielleicht bei der Erfassung des Überblicks oder in Bezug auf Facetten, sie reduziert aber nicht die Komplexität des realen Systems und verführt uns so zu möglichen Kurzschlüssen und Fehlentscheidungen. Wir sollten uns gerade auch bei der Erstellung von Reports und Auswertungen stets ihrer Unvollkommenheit bewusst sein. Mitunter ist hier weniger mehr: Wenige Zahlen, die wir aber vernünftig einordnen und erklären können, deren Grenzen uns bewusst sind, sind besser als pseudowissenschaftliche Tiefe, deren Grundannahmen auf fragilen Mauern stehen, uns aber aufgrund ihrer vermeintlichen Exaktheit eine falsche Glaubwürdigkeit suggeriert. Allzu oft tappen wir in eine psychologische Falle und glauben viel leichter an die Richtigkeit einer Aussage, weil sie vermeintlich bis auf 2-Nachkommastellen belegt ist.

#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

 

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

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.

#623 schlossBlog wird 8


Kaum zu glauben, aber der schlossBlog wird in diesen Tagen 8 Jahre alt!

Älter wie meine Tochter, manchmal auch frecher wie sie…

Nicht ganz so alt wie mein Sohn, aber der Blog hat ja auch Vorläufer-Aktivitäten in statischen Firmenseiten und privaten Web-Versuchen, die ihn dann altersmäßig auch noch überholen. Langsam erklären sich die grauen Haare auf meinem Kopf.

Zeit allen Lesern und Begleitern zu danken. Ich freue mich schon auf die vielen Themen und Ideen, die hier, auf openPM oder an anderen Stellen noch vor uns liegen!

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

#621 Gelesen: UZMO

 

Martin Haussmann, UZMO – Denken mit dem Stift: Visuell präsentieren, dokumentieren und erkunden, München 2014, ISBN-13: 978-3-86881-517-7

 

Ein Buch ganz nach dem Geschmack des visualPM! Es gibt so wunderbare Bücher zum Thema Visualisierung und UZMO ist eines davon. Setzt man die Buchstaben „UZMO“ neu zusammen und zwar nicht als Wort, sondern als Grafik, so entsteht eine Glühbirne: U und Z übereinander gibt das Gewinde, O den Glaskörper und das M den Draht. (Es ist natürlich gemein, darüber zu schreiben ohne das Bild zu zeigen, aber vielleicht funktioniert ja das Kopf-Kino!)

UZMO lehrt uns mit der bikablo-Zeichentechnik eine visuelle Sprache. Visuelles Arbeiten ist nicht nur eine eigene Kommunikationsform, sondern gibt uns einen zusätzlichen Kanal für Resonanz und Feedback neben der verbalen Sprache. Dabei kommt es auch gar nicht auf Perfektion an:

„Das Ziel von Visualisierung ist nicht Schönheit, sondern Kommunikation.“

Martin Haussmann erläutert nicht nur die Grundlagen, sondern gibt konkrete Hilfen und Werkzeuge in einem selbstverständlich auch visuell schön gestaltetem Buch. Zu den vorgestellten Werkzeugen gehören neben der bikablo-Technik, u.a. der Visualisierungskompass, der uns den Weg zu geeigneten Darstellungsformen weist, die Symbol-Safari, die uns hilft eine eigene visuelle Sprache für unsere eigenen Themen zu entwickeln, die Plakatmaschine, Sketchnoting, die Problemlösungstechnik Riesenrad, Templates, sowie zahlreiche Vorlagen, Anleitungen und Tipps und vieles mehr. Eine echte Empfehlung, die Lust macht die Werkzeuge auch auszuprobieren.

Martin Haussmann, seine bikablo Kollegen von den Kommunikationslotsen und der Webshop Neuland zählen zu den deutschsprachigen Vorreitern im Visual Facilitating (Wikipedia).

Ebenfalls von Martin Haussmann (gemeinsam mit Holger Scholz) gibt es auch das bikablo Trainerwörterbuch der Bildsprache/Facilitators dictionary of visual language, wobei ich ehrlich gesagt hier das Buch Bildsprache: Formen und Figuren in Grund- und Aufbauwortschatz von Petra Nitschke bevorzuge.

 

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

#619 Mal ein HR-Beitrag: Der härteste Job der Welt!