Archiv der Kategorie ‘Qualitätsmanagement‘

 
 

Best of… All time high: Testmanagement in IT-Projekten

Um ehrlich zu sein, ist es mir selbst ein Rätsel warum, aber das Testmanagement in IT-Projekten ist jetzt über Jahre dauerhaft der meistgefragteste Content auf schlossBlog.

Die Artikel für das Projektmagazin sind bereits aus dem Jahr 2009. Die Zusammenfassung gibt es auch als Präsentation:

Oder im Original beim Projektmagazin (Abodienst):
Teil 1: Ablauf und Organisation
Teil 2: Das Excel-Toolset

Best of… Die Anforderungspyramide

Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.

Der ursprüngliche Post stammt aus dem Jahr 2017.

Qualitativ vs. quantitaiv

Zahlen haben fast schon eine „magische“ Wirkung auf uns. Wir schenken ihnen Vertrauen und sie liefern uns exakte Aussagen.

Schön wäre es, denn im Detail liegen ein paar Tücken: Messen bzw. zeigen die Zahlen tatsächlich das, was sie vermeintlich vorgeben zu zeigen? Und mit welcher Zuverlässigkeit und Genauigkeit tun sie es?

Die Krux mathematischer Modelle und Berechnungen liegt darin, dass sie uns Ergebnisse mit Nachkommastellen liefern. Das aber ist lediglich eine Scheingenauigkeit, denn das Ergebnis kann nicht besser sein als das zugrundeliegende Modell. Wie sehr uns das überfordert, zeigt der aktuelle Umgang mit den Covid Statistiken. Von uns Laien werden Zahlen vogelwild interpretiert ohne das wir wirklich wissen, was sie aussagen, ohne das wir statistische Effekte aus Erfassung und Verarbeitung, wie z.B. durch die Änderung der Teststrategie oder das Meldeverhalten, berücksichtigen.

Wir sind in guter Gesellschaft. Seit langem bemängelt  Gerd Gigerenzer (Amazon Affiliate Link), dass die meisten Mediziner, medizinische Wahrscheinlichkeitsaussagen nicht interpretieren können. Wie soll das dann bei Covid anders sein?

Oder im Risikomanagement?

Die bekannteste Quantifizierung eines Risikos ergibt sich aus der versicherungmathematischen Formel als Produkt von Eintritswahrscheinlichkeit und potentiellem Schaden, dem sogenannten Erwartungwert.

Aber welche Aussagekraft hat der Erwartungswert?

Nun statistisch gesehen, ist das der durchschnittlich zu erwartende Schaden. Aber nutzt uns das was? Das ist in etwas wie die durchschnittliche Fiebertemperatur aller Krankenhauspatienten. Nehmen wir einmal an, ein Unternehmen würde aufgrund eines solchen Modells finanzielle Rückstellungen in Höhe des Erwartungswerts treffen. Bei Risiken die digital eintreten, d.h. sie treten entweder ein oder sie treten nicht ein, stecken wir in dem Dilemma, dass wir im einen Fall zu niedrige und im anderen Fall zu hohe Rückstellungen getroffen haben. Worst case ist beides existenzbedrohend, z.B. im Falles des Eintretens eines „schwarzen Schwans“ (Amazon Affilitate Link), also eines äußerst unwahrscheinlichen Ereignisses – z.B. einer Covid-Pandemie….


Den ganzen Beitrag lesen…

Likes für #QM

Selbst ein so undankbares und abstraktes Thema wie Qualitätsmanagement in Projekten findet Anklang. Ich bin angetan. Schon 86 Likes.

Die Anforderungspyramide

Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.
 

Fehlerkultur

Das Thema Fehler und Fehlerkultur hat mich jüngst über mehrere Wege eingeholt: Zum Einen bei der Erstellung unseres Qualitätsmanagementtrainings für die LinkedIn Learning Projektmanagement Reihe und zum Anderen über eine Diskussion ausgelöst durch einen Blogpost von Marcus Raitner gefolgt von einigen Repliken, u.a. von Stephan List auf dem Toolblog.

Was mir gar nicht gefällt ist die Verquickung der Begriffe Fehler und Scheitern. Während ein Fehler ganz neutral lediglich ein Ergebnis darstellt, das so weder erwartet noch gewollt war, birgt Scheitern eine stark persönlich wertende Konotation: Eine negative Wertung über die Leistungserbringung und den Leistungserbringer. Insofern würde ich gerne Marcus These („Scheitern erlauben – Fehler abschaffen“) etwas provokant auf den Kopf stellen:

Fehler erlauben – Scheitern abschaffen!

Ganz klar: Es geht nicht um unnötige und fahrlässige Fehler, aber es geht um Fehlerkultur. Es geht um einen konstruktiven Umgang mit Fehlern. Aktuelles Negativbeispiel ist wieder das Dieselgate und der desaströse Umgang damit in Politik und den betroffenen Firmen.

Aber was ist dann eine Fehlerkultur? Was macht eine (positive) Fehlerkultur aus?

(1) Akzeptanz von Fehlern
Fehler passieren. Ob wir wollen oder nicht. Dafür ist unsere Welt viel zu komplex, als dass wir alles kontrollieren könnten. Es ist sinnlos das zu negieren, vielmehr sollten wir den konstruktiven Umgang mit Fehlern suchen.

(2) Keine Schulddebatten
Beim konstruktiven Umgang mit Fehlern geht es nicht um die Schuldfrage, sondern um Lösungen. Es geht nicht um willfährigen, vorauseilenden Gehorsam, der nur auf das achtet, was vermeintlich erwartet wird, sondern um eine ehrliche und sachliche Auseinandersetzung.

(3) Transparenz
Wir brauchen selbstverständlich im Team Transparenz über unsere Fehler und Probleme. Das ist natürlich nur möglich, wenn niemand negative Konsequenzen aus seiner Ehrlichlkeit fürchten muss. Hier schließt sich der Kreis zur Schulddebatte. Es geht eben nicht um Fingerpointing auf Personen, sondern um Sachlichkeit.

(4) Fehlervermeidung kein Selbstzweck
Natürlich wollen wir keine unnötigen Fehler, aber Fehlervermeidung darf auch nicht zur Selbstzensur werden. Wir brauchen Handlungs- und Experimentierfreiräume um Lernen zu können und voran zu kommen. Das Negativbeispiel hier ist der Sprachenschüler, der seinen Mund nicht aufkriegt aus Angst einen Fehler zu machen und damit grandios an seinem Ziel – der Kommunikation – scheitert (upps, jetzt habe ich selbst von Scheitern gesprochen), statt mit Händen und Füßen zu kommunizieren und sein eigentliches Ziel zu erreichen. Die Fehlervermeidung an sich ist nicht das Ziel, sondern (in diesem Fall) die Kommunikation, aber das wird mitunter vergessen.

Wir brauchen also einen entspannteren Umgang mit Fehlern, aber keinen leichtfertigen, einen sachlichen und ganz bewussten.

Und auf die Energieverschwendung für Eitelkeiten und Schulddebatten können wir im Sinne des Teams gerne verzichten.

#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 (Amazon Affiliate Link) 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.



bernhardschloss.de