Archiv der Kategorie ‘Qualitätsmanagement‘

 
 

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

#563 Geführte Retrospektive

Eine lesenswerte Beschreibung von Lessons Learned, Rückblick und Retrospektiven hat Eberhard Huber vor einer Weile für openPM erstellt.

Eine Retrospektive kann dazu dienen:

  • Know How zu sichern
  • Prozesse zu verbessern
  • Kommunikation zu verbessern
  • das Gruppenklima zu verbessern (bzw. der Teamentwicklung zu dienen)

Retrospektiven/Rückblicke/Lessons Learned sind normalerweise gekennzeichnet durch Offenheit (in der Fragestellung) und Respekt (unter den Teilnehmern). Es geht nicht um „Fingerpointing“ und Schuldzuweisungen, sondern um konstruktive Weiterentwicklung. Jede Meinungsäußerung muss als subjektive Sichtweise akzeptiert werden und bringt, selbst wenn sie objektiv nicht zu halten ist, den Spannungsbogen in der Gruppe zum Ausdruck. Niemand wird gezwungen eine Sichtweise zu teilen, oft hilft es aber die Sichtweisen der anderen zu kennen und zu verstehen.

Ich habe sehr gute Erfahrungen gemacht mit einer Art geführten Retrospektive. Dabei haben wir uns nicht auf der grünen Wiese (oder besser: einem weißen Batt Papier) gefragt, was gut läuft und was weniger gut, sondern haben uns beispielsweise an dem High-Level-Prozess einer Abteilung orientiert, um systematisch das ganze Feld der Gruppe abzudecken. In einem anderen Beispiel habe ich eine Mindmap vorbereitet in der bestimmte (ganz wenige) Äste bereits vorgegeben waren (z.B. ein Ast „Kommunikation“), um auch direkt bekannte Probleme zu adressieren und ein drumherum Reden um den heißen Brei zu verhindern. Als sehr hilfreich habe ich dabei erlebt, die Teilnehmer auch bei kritische Themen aufzufordern zu sammeln, was selbst hier positiv gelaufen ist. Gruppen wissen meist sehr wohl, wenn es in ihrer Kommunikation hakt, aber bei Einhaltung der Lessons Learned-Regeln und einer bewussten Frage nach positiven Aspekten wird eine differenzierte Betrachtung angeregt. Die von Eberhard beschriebene Offenheit und Kultur muss dabei aber erhalten bleiben. Und wenn die Teilnehmer die Äste und Struktur verändern, dann verändern sie diese. Die Führung durch die Vorgabe soll nur eine Hilfestellung sein und kein Diktat.

#550 Was können wir aus Großprojekten lernen?

Christian Vogel hat auf openPM eine Diskussion anlässlich der aktuellen BER-Geschichte gestartet.

Hallo Dummköpfe! Hallo Lügner!  – Diskutiert mit!

(Diese Anrede ist geklaut aus einem Google+ Post von Heiko Bartlog und bezieht sich auf einen Artikel des Planungsexperten Bent Flyvbjerg, der u.a. bei Spiegel online derzeit die Runde macht.)

Übrigens: Ich bin auch ein Lügner und Dummkopf!

#498 Risikomanagement und Wahrnehmung

Nach all der Euphorie aus dem PM Camp muss auch noch Platz bleiben für andere Themen (auch wenn es danach wieder mit PM Camp weitergeht)!

Die gestern erschienen RiskNEWS enthalten einen interessanten Beitrag zum Thema Risikomanagement: Risiko ist ein Konstrukt der Wahrnehmung von Dr. Stefan Hirschmann. Die Wahrnehmung von Risiken ist hochgradig individuell und wird von vielen Faktoren beeinflusst.

#487 Gelesen: Das Spiel. Brennpunkt Geschäftsprozesse

Mit zahlreichen Fußballanalogien und -weisheiten führt uns Alexander Ockl durch ein Praxisbeispiel der Geschäftprozessgestaltung zwischen IT und Fachbereich. Er wählt dabei eine Romanform, wie man sie z.B. von DeMarco´s PM-Klassiker „Der Termin“ 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 

#441 Scrum-Konferenz: Agilität und Kultur

Diesmal Ralf Westphal über „Agilität und Kultur“ im Interview mit Patrick Fritz. wie gewohnt hier eine Zusammenfassung:

Eine entsprechende Kultur ist die Voraussetzung, damit sich Agilität in einem Unternehmen durchsetzen kann. Ralf zitiert hierzu den Management-Guru Peter Drucker:

Culture eats strategy for breakfast.

Die Kultur spiegelt sich wieder im Umgang mit Zeit, Fehlern, Fokus und Arbeitsbedingungen.

Agilität hat eigentlich nichts mit SW-Entwicklung zu tun. Ralf meint vielmehr:

It´s a way of life.


Den ganzen Beitrag lesen…

#377 Zusammenfassung Lessons Learned

Eine Zusammenfassung zum Thema Lessons Learned liefert Steffen Jung auf Green Light.

#351 Logbuch

Lukas Pustina gibt Tipps zum Thema Logbuch.

Auch auf schlossBlog gab es hierzu schon zwei Beiträge:

#327 Was Tester testen sollen

Und noch einmal Pawel Brodzinski, der sich mit einem Beitrag von Jennifer Bedell auf PMStudent zum Thema Testmanagement auseinander setzt: Testen kann auch ausufern, wenn der Scope des Projekts aus dem Auge verloren wird und weit über die ursprünglichen Projektauftrag hinaus getestet wird. Zurecht weist Pawel darafhin, dass die Erfüllung von Spezifikationen mitunter noch wenig über die tatsächliche Qualität des Ergebnisses aussagt. Auch wenn alle Anforderungen erfüllt sind, kann der Patient bereits tot sein. Der Test der Spec stelllt quasi den minimalen Testumfang dar,  aber um die Qualität sicherzustellen braucht es „mündige Tester“, die auch nach rechts und links schauen, aber mit Augenmaß, um nicht einfach den Projektauftrag beliebig zu erweitern und die Kosten aus dem Ruder laufen zu lassen.

#326 Agil? So what!

Pawel Brodzinski bringt es auf den Punkt: Bei aller Methoden-Diskussion – letztlich zählt nur das Ergebnis und dessen Qualität, da sollte es keine Rolle spielen ob das mit agilen oder klassischen Methoden erreicht wurde. Auch die beste Methode ist bei fehlendem Qualitätsbewußtsein unzulänglich. Pfusch bleibt Pfusch!