Alle Artikel

Die sieben Werkzeuge der Qualität im Projektmanagement

Was ich mir von anderen für die Qualitätssicherung in meinen Projekten abschauen kann.

Qualitätssmanagement bei Projekten

75 Jahre ist es her, da hat Ishikawa Kaoru seine sieben Werkzeuge der Qualität (Q7) definiert. Moment mal, Ishikawa, da war doch was. Genau, das Fishbone-Diagram, auch Ishikawa-Diagramm genannt. Derselbe Ishikawa. Chemiker und Vordenker der Company-wide Quality Control. Ein Konzept zur Qualitätssicherung, das vor allem in der Industrie und in Produktionsbetrieben weit verbreitet ist, weil es klare Definitionen beinhaltet und vor allem den menschlichen Faktor mehr in den Mittelpunkt stellt als z.B. Total Quality-Management. Und wie so oft, können wir Projektarbeiter von anderen Bereichen sehr viel lernen und mitnehmen. Also sehen wir uns die sieben Werkzeuge mal näher an.

Das Ishikawa-Diagramm

Nachdem wir gerade davon geredet haben und nachdem es im Projektmanagement gern verwendet wird, beginnen wir mit dem Fishbone-Diagramm. Warum das so heißt? Weil es ein wenig so aussieht wie Gräten. Ishikawa nannte es Ursache-Wirkungs-Diagramm und das ist auch gleich eine gute Beschreibung, was ich damit machen kann. Es hilft mir, die Gründe zu eruieren, warum ein bestimmtes Ereignis - meist ein Problem - eingetreten ist. Die Anwendung ist sehr einfach, wenn man sich an folgende fünf Schritte hält:

  1. Zeichnet einen Pfeil nach rechts und schreibt an die Spitze Euer Problem, z.B. Das Projektteam ist wenig motiviert.
  2. Findet alle Ursachen für das Problem, clustert sie und schreibt sie auf schräge Striche, die zum Pfeil hinführen (die Fischgräten).
  3. Überprüft nochmal, ob nicht noch ein potentieller Auslöser des Problems fehlt.
  4. Gewichtet die Ursachen und findet die mit der höchsten Wahrscheinlichkeit. Und
  5. Diskutiert nochmal, ob ihr wirklich die Quelle des Übels gefunden habt.

Und ja, bei komplexeren Problemstellungen wird das Fishbone-Diagramm schnell unübersichtlich. Aber es bringt das ganze Team dazu, sich Gedanken über Risiken und ihre Ursachen zu machen. Und in Kombination mit der 5-Why-Technik ist es ein wertvolles Tool, um Krisensituationen besser greifbar machen zu können.

Das Paretodiagramm

Und schon wieder ein alter Bekannter. Diesmal Vilfredo Pareto, der Formulierer des berühmten Pareto-Prinzipes (auch 80-20-Regel genannt), das alle kennen und über das alle gerne stolpern. Und auf diesem Prinzip beruht auch das Diagramm, mit dem ich hervorragend Fehleranalyse betreiben kann.
Zur Erstellung nehme ich mir die Ursachen eines Problems (die habe ich idealerweise bereits beim Erstellen des Fishbone-Diagramms gesammelt), lege mich auf eine Messgröße fest (Häufigkeit, Kosten, etc.) und ermittle für jede Ursache den Anteil am Gesamtaufwand (also den Anteil an der Gesamthäufigkeit, an den Gesamtkosten, und so weiter). Dann sortiere ich sie nach Größe und weiß somit, welche Ursachen mir wirklich die größten Bauchschmerzen verursachen.

Wenn mein großes Projekt langsam in Schieflage gerutscht ist (sowas passiert nicht nur Euch ab und zu, keine Sorge - das kommt auch in den besten Häusern regelmäßig vor) und ich nicht genau sagen kann, was die Ursache dafür ist und vor allem was aktuell mein größtes Problem ist, ist das Pareto-Diagramm gold wert. Selbst wenn ich es nicht wissenschaftlich und detailgetreu erstelle, sondern nur grob, zeigt es mir, worauf ich aktuell mein Hauptaugenmerk legen sollte.

Das Prüfblatt

Ich bin schon öfter zu Projekten gestoßen, in denen viel und richtig gemessen wurde. Aber wie so oft sieht man dann den Wald manchmal vor lauter Bäumen nicht. Hier ist das Prüfblatt ein treues Helferlein. Wobei Prüfblatt so ein technokratisches Wort ist. Die meisten Menschen sagen dazu Stricherlliste. Und damit hab ich auch schon den Verwendungszweck. Eine Liste auf der ich Daten sammeln kann. Das kann ein Stück Papier sein oder ein Dokument auf meinem Rechner. Ich würde ersteres empfehlen - low tech, high touch. Und ja, es ist ein wahnsinnig einfaches Tool. Aber auch ein wahnsinnig mächtiges. Weil damit jede und jeder DAten erfassen kann. Ohne lange Schulung und vor allem ohne große Hürde.

Das Quality Control Chart

Und wieder ein Begriff, den wir alle kennen. Control Charts begegnen wir häufig in Projektmanagementbüchern. In meinen Augen werden sie nur viel zu selten eingesetzt.
Im Grunde ist ein Control Chart (ich frage mich ja oft, wie man auf den Terminus Regelkarte kommt - schlimmer übersetzt als die deutschen Titel von James Bond-Filmen) eine waagrechte Linie auf einem Zettel. Jetzt brauche ich noch einen Prozess, den ich messen will und Daten, die ich messen kann. Zum Beispiel Softwareerstellung und Bugs in dieser Software. Und wenn ich regelmäßig die Anzahl dieser Bugs auf meinem Zettel mit einem Punkt markiere (in dem Fall ist die Linie auf dem Zettel die Nulllinie), bekomme ich nach einiger Zeit einen Überblick, wie sich die Anzahl der Bugs in meiner Software entwickelt. Zeigt der Trend nach unten? Gut. Wandern die Punkte nach oben? Zeit, einzugreifen. Und wenn ich mich nicht auf mein Bauchgefühl verlassen will, ab wann ich eingreifen muss, kann ich im Vorhinein Grenzen definieren, ab denen ich tätig werde.

Ich weiß, die Pflege von Control Charts ist furchtbar mühsam, zeitraubend und oft umsonst gewesen. Aber wenn Ihr das ein paar Projekte lang tapfer durchzieht und vor allem auf die Erfahrungen Eurer Projektteams hört, bekommt Ihr schnell ein Gespür dafür, welche Prozesse und deren Stabilität unbedingt mittels Quality Control Chart beobachtet werden müssen. Auch und vor allem im agilen Bereich bekommt Ihr dann einen unglaublich wertvollen Problemeradar, der mir schon oft den Allerwertesten gerettet hat.

Flowcharts

Auf deutsch Programmablaufplan genannt - die nächste Technokratenübersetzung. Flowcharts sind im Prozessmanagement sehr beliebt und waren früher auch in der Softwareentwicklung gang und gäbe. Das und die formal engen Grenzen schrecken viele davon ab, sie zu verwenden. Aber für mich sind sie wahnsinnig wertvoll. Nämlich zu Beginn eines Projektes, wenn noch keine Work Breakdown Structure erstellt wurde und die Abläufe für mich noch nicht greifbar sind. Dann setze ich mich hin, nehme einen Stift und ein großes Blatt Papier und kritzle einfach drauf los, wie das Projekt so ablaufen könnte. Ich weiß, da gibt es wahnsinnig viele Regeln, wie so ein Flowchart auszusehen hat (UML und Konsorten lassen grüßen). Vergesst sie! Ein großer Kringel ist mein Startpunkt, Rechtecke sind potentielle Meilensteine und Pfeile zwischen den Rechtecken sind eine Mischung aus Phasen und geclusterten Arbeitspaketen.
Irgendwann sieht dieses Blatt Papier dann aus, als wäre ein Plotter Amok gelaufen. Und wirklich konkret ist es auch nicht. Aber ich habe ein Gefühl dafür bekommen, wie mein Projekt in etwa ablaufen wird. Und damit kann ich dann viel schneller meine WBS erstellen.

Das Histogramm

Wer weiß, was ein Histogramm ist, fragt sich jetzt vielleicht, was es im Projektmanagement verloren hat und ob es nicht doch besser in der Produktion aufgehoben ist. Aber so ein Histogramm ist sehr hilfreich, wenn ich dabei bin, meine Ressourcen zu planen. Weil es mir hilft, meinen Bedarf und meine Kapazitäten zu vergleichen. Vor allem bei mehreren Projekten, die parallel im selben Umfeld abgewickelt werden und vor allem auch bei meinem Ressourcenmanagement in agil abgewickelten Projekten.

Im Grunde genommen besteht ein Histogramm aus zwei Achsen. Auf der x-Achse habe ich meine Zeit (Sprints, Tage, Kalenderwochen, Jahre), auf der y-Achse habe ich meinen Bedarf (Story Points, Manntage, Ideale Arbeitstage). Und jetzt gehe ich her und zeichne entlang der x-Achse meinen Ressourcenbedarf laut Projektplänen ein. Wenn mehrere Bedürfnisse zur selben Zeit auftreten, staple ich sie. Excel ist hier super geeignet, Stift und Papier tun es auch.
So ein Histogramm zeigt mir also auf einen Blick, wann ich meine Kapazitäten überschreite und ich kann entsprechend vorausplanen und priorisieren.

Das Streudiagramm

Wenn ich wissen möchte, ob zwischen bestimmten Messungen ein Zusammenhang besteht, hilft mir das Streudiagramm weiter. Und hier habe ich vor allem im agilen Projektmanagement ein wichtiges Tool: mittels Streudiagramm kann ich die Dauer meiner Iterationszyklen messen und sichtbar machen. Das inspect von inspect and adapt.
Auch hier habe ich eine x- und eine y-Achse. Ähnlich wie beim Histogramm befindet sich auf der x-Achse die Zeit. Auf der y-Achse notiere ich die Zyklusdauer all der Aufgaben, die in diesem Zeitrum fertiggestellt wurden. Und wenn ich das über einen längeren Zeitraum mache, kann ich auch die wahrscheinliche Dauer von zu erledigen Aufgaben recht gut schätzen. Mit dem Streudiagramm schlage ich also zwei Fliegen mit einer Klappe.

Nicht alles alte ist schlecht

Jetzt sind die eingangs erwähnten 75 Jahre in ganz schön lange Zeit. Vor allem, wenn man bedenkt, dass das Projektmanagement als Disziplin erst in den 50er Jahren aufgekommen ist. Und auch unabhängig davon, hat sich seit 1943 sehr viel verändert. Das ist auch der Grund, warum die Q7 mittlerweile im Prozessmanagement, der Qualitätssicherung und der Produktion von moderneren Modellen abgelöst wurden. In diesen Bereichen sind sie für unsere heutigen Ansprüche zu einfach gestrickt. Aber im Projektmanagement, wo das Qualitätsmanagement ein Teilbereich und nicht das große Ganze ist, sind sie gerade wegen ihrer Einfachkeit sehr wichtige Helferleins, die uns viel Kopfschmerzen ersparen können.

Bilder von NEW DATA SERVICES auf Unsplash.

Gedanken über modernes Projektmanagement - klassisch, agil, hybrid. Stephan Weinhold ist auch auf LinkedIn und XING. Du solltest ihm außerdem auf Twitter folgen.