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