Mangelndes QM kommt teuer zu stehen Qualität im Projekt planen, lenken, prüfen

Teil 2:
Pragmatischer Lösungsansatz für Projektmanager
IT-Projektmanager müssen das Dilemma zwischen Notwendigkeit und mangelnder Akzeptanz von Qualitätsmanagement überwinden. Kay Schulz beschreibt anhand von Beispielen aus seiner Erfahrung eine pragmatische Vorgehensweise, wie er das Thema "Qualitätssicherung" mit kleinen, aber ganz konkreten Schritten ins Projekt einbringt. Kern dieses am EFQM-Modell orientierten Vorgehens, das er an das jeweilige Projektumfeld anpasst, sind die drei Elemente Qualitätsplanung, Qualitätslenkung und Qualitätsprüfung.

 

Download PDFDownload PDF

Mangelndes QM kommt teuer zu stehen Qualität im Projekt planen, lenken, prüfen

Teil 2:
Pragmatischer Lösungsansatz für Projektmanager
IT-Projektmanager müssen das Dilemma zwischen Notwendigkeit und mangelnder Akzeptanz von Qualitätsmanagement überwinden. Kay Schulz beschreibt anhand von Beispielen aus seiner Erfahrung eine pragmatische Vorgehensweise, wie er das Thema "Qualitätssicherung" mit kleinen, aber ganz konkreten Schritten ins Projekt einbringt. Kern dieses am EFQM-Modell orientierten Vorgehens, das er an das jeweilige Projektumfeld anpasst, sind die drei Elemente Qualitätsplanung, Qualitätslenkung und Qualitätsprüfung.

 

Qualitätssicherung für IT-Projekte stößt meiner Erfahrung nach sowohl bei Projektteams als auch bei Unternehmen meist auf Ablehnung: Teammitglieder, Auftraggeber und Linienmanager befürchten zu großen Verwaltungsaufwand, Lieferverzögerungen und zusätzliche Kosten, wenn Qualitätsmanagement ganzheitlich in Projekten eingeführt wird. Im ersten Teil dieses Artikels habe ich anhand von Beispielen aus meiner Erfahrung die negativen Konsequenzen beleuchtet, die sich aus dieser mangelnden Akzeptanz ergeben.

Vor diesem Hintergrund möchte ich im Folgenden eine pragmatische Vorgehensweise beschreiben, wie ich das Thema "Qualitätssicherung" mit kleinen, aber ganz konkreten Schritten ins Projekt einbringe. Dabei orientiere ich mich an der Darstellung von Bruno Jenny (Jenny, 2014) und an den Rahmenbedingungen des EFQM-Modells (siehe http://www.efqm.org), die ich bereits im ersten Teil vorgestellt habe. Je nach Unternehmenskultur, Projektart und anderen Faktoren passe ich dieses Vorgehen an, doch sein Kern bleibt gleich: Qualitätsplanung, Qualitätslenkung und Qualitätsprüfung.

Schritt 1: Qualitätsplanung

Mit dem Sponsor und den wichtigsten Stakeholdern bespreche ich, was wir unter Qualität im Allgemeinen verstehen, sodann, was wir konkret erreichen wollen und welche Ansprüche wir an die Qualität haben. Das gilt sowohl für die Qualität des zu liefernden Produkts als auch für die Qualität des Abwicklungsprozesses. Aus der Dokumentation der Ergebnisse dieser Gespräche entsteht der Qualitätsplan (=Qualitätssicherungsplan, Qualitätsmanagementplan) für das Projekt.

Der Qualitätsplan sollte u.a. folgende Informationen enthalten (vgl. Jenny, 2014, S. 567):

  • Ziele des Qualitätsmanagements für das Projekt
  • Referenzierte Dokumente (z.B. Qualitätsmanagement-Dokumente des Unternehmens)
  • Rollen und Verantwortlichkeiten für das Qualitätsmanagement
  • Festlegen von Vorgehen, Verfahren, Konventionen (z.B. Prozesse, Zusammenarbeit mit externen Unternehmen, anzuwendende Richtlinien)
  • Planung von Maßnahmen zur Qualitätssicherung (Reviews, Tests, Audits usw.)
  • anzuwendendes Entwicklungskonzept (z.B. Scrum, Wasserfall usw.)
  • Lieferantenkontrolle (d.h. wie wird die Zuarbeit von Lieferanten hinsichtlich Qualität überwacht?)
  • Wer führt welche Qualitätsaktivitäten wann und wie durch? (Prüfplan, s.u.)

Um diese Informationen zu erhalten, setze ich gerne das EFQM-Modell als eine Art Checkliste für Gespräche mit den Stakeholdern ein.

Konzept für Qualitätssicherung gemäß EFQM-Modell

Ich lege mit dem Sponsor und dem Projektteam fest, ob wir uns am EFQM-Modell (siehe Teil 1) orientieren und welche Teile wir ggf. herausnehmen oder neu gewichten. Die "Enabler" des EFQM-Modells beschreiben dabei die Qualität der Projektdurchführung, die "Results"-Aspekte charakterisieren die Lieferung. Das dabei entstehende Konzept für die Qualitätssicherung sah in einem Projekt dann vereinfacht so aus:

Tabelle 1: Beispiel eines Konzepts für die Qualitätssicherung anhand der Gliederung des EFQM-Modells.
Tabelle vergrößern

In Tabelle 1 habe ich die vier "Results" des EFQM-Modells frei mit "Zufriedenheit" übersetzt, da mir dies als die relevante Ergebnisgröße für ein Projekt erscheint. Die Tabelle zeigt, in wie weit wir uns an das EFQM-Modell hielten und wie wir seine einzelnen Aspekte konkretisierten.

Wir planen zusammen die Qualität und legen die Qualitätsziele fest. Der Qualitätsplan sollte diese Ziele sowie ggf. zu referenzierende Dokumente, bei Bedarf auch die für die Qualitätssicherung verantwortliche Organisationsstruktur umfassen.

Allgemeine Qualitätskriterien

Anschließend vereinbaren wir die übergeordneten Qualitätsmerkmale, die bei Reviews zu prüfen sind. In den meisten Software-Entwicklungsprojekten hat die Korrektheit der Software die höchste Bedeutung, d.h. dass jede Funktion exakt das liefert, was erwartet wird. Die Funktionsabdeckung ist für die meisten Sponsoren ebenfalls sehr wichtig, allerdings leitete ich schon mehrere Projekte, bei denen wir den Umfang reduzierten, um termingerecht und innerhalb des Budgets liefern zu können. Je nach Projekt und Software können weitere Kriterien (nicht-funktionale Anforderungen) von Bedeutung sein, wie z.B.:

  • Anpassbarkeit des Codes
  • Wiederverwendbarkeit der gesamten Software oder bestimmter Teile
  • Antwortszeiten bzw. Verarbeitungsgeschwindigkeit
  • Benutzerfreundlichkeit

Fortsetzungen des Fachartikels

Teil 1:
Qualitätssicherung? Das behindert nur unser Projekt!

Qualitätssicherung stößt in IT-Projekten meist auf mangelnde Akzeptanz. Kay Schulz schildert anhand zahlreicher Beispiele die negativen Konsequenzen unzureichender Qualitätssicherung.

Alle Kommentare (2)

Guest

Wie aus Teil 1 zu erwarten war und wie ausdrücklich angekündigt enthält der Sicht des Autors und seine Arbeitsweise zu dem Thema. Leider geht dabei die sonstige Bewegung auf dem Markt zu diesem Thema unter. So drängt sich zum Beispiel die Frage (nur eine von sehr vielen) auf, warum mit dem generischen Modell der Business Excellence gearbeitet wird, obwohl sich seit Jahrzehnten das Modell der Project Excellence bewährt hat. Auch hier möchte ich dem Autor danken, dass er mit seinem Artikel in das Thema einführt und das so einseitig und subjektiv, dass eine Diskussion dazu entstehen muss.

 

Kay
Schulz

Sehr geehrter Herr Schmidt, Danke für den Kommentar. Wir haben das Project Excellence Modell, das sich aus dem EFQM ableitet, oben dargestellt. Wenn Sie meine Artikel kennen, werden Sie feststellen, dass ich versuche, keine allgemeingültigen Artikel zu schreiben, sondern immer aus meine Erfahrungen zu berichten. Diese sind subjektiv. Und aus diesen Erfahrungen anderen die Möglichkeit zu geben, zu lernen. Mit freundlichen Grüssen