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

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. Er legt dar, dass sich Fehlerkosten und durch Fehler bedingte Verzögerungen nur durch eine auf die Bedürfnisse des Projekts angepasste Qualitätssicherung vermeiden lassen. Anhand von Normen und Richtlinien zeigt Schulz den Weg zu einem Lösungsansatz für Projektmanager auf, um das Dilemma zwischen Notwendigkeit und mangelnder Akzeptanz von QM zu überwinden.

 

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

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. Er legt dar, dass sich Fehlerkosten und durch Fehler bedingte Verzögerungen nur durch eine auf die Bedürfnisse des Projekts angepasste Qualitätssicherung vermeiden lassen. Anhand von Normen und Richtlinien zeigt Schulz den Weg zu einem Lösungsansatz für Projektmanager auf, um das Dilemma zwischen Notwendigkeit und mangelnder Akzeptanz von QM zu überwinden.

 

Wenn ich ein laufendes Projekt übernehme, dann bitte ich das Projektteam, mir für einen schnellen Einstieg u.a. die folgenden Dokumente bereitzustellen:

die drei letzten Statusberichte

das aktuelle Protokoll des Lenkungsausschusses

die Risikoliste und die Dokumentation des Risikomanagement-Prozesses

den Qualitätsplan

Bei der Frage nach dem Qualitätsplan bekomme ich in der Regel eine von drei Antworten:

  • "Haben wir nicht!"
  • "Hier ist die Liste der durchgeführten Test Cases und wie viele davon erfolgreich waren!"
  • "Der liegt bei der Abteilung für Quality Assurance!"

Frage ich weiter nach, ob sie CMMI oder Lean Six Sigma zur Qualitätssicherung verwenden, erhalte ich als Reaktion meist nur Staunen, für das es zwei Gründe gibt:

  1. Die Kollegen kennen diese Begriffe nicht.
  2. Sie wundern sich, wie ich auf die Idee komme, diese "komplexen, zeitintensiven und teuren" Konzepte könnten in diesem Unternehmen bzw. in diesem Projekt eingesetzt werden.

Zusätzlich erhalte ich meistens die Antwort, dass die Software von der IT und dem Fachbereich getestet werde, und dass dies als Qualitätssicherung ausreiche, da das Unternehmen für zusätzliche Aufwände kein Geld und das Projekt dafür keine Zeit habe.

"Qualität? Brauchen wir nicht!"

In einem Projekt, in dem nur der Code getestet wurde und auch keinerlei Vorgaben bestanden, wann die Tests als erfolgreich zu bewerten waren ("… wenn alle Testfälle erfolgreich abgeschlossen sind …"), lud ich kurz nachdem ich es übernommen hatte zu einer Besprechung ein. Ich wollte in einem Workshop gemeinsam definieren, was im Projekt unter Qualität verstanden wird oder was wir als Team darunter verstehen wollen. Der Termin wurde von allen Teilprojektleitern und Architekten, ja sogar von den beiden Testmanagern (IT und Fachbereich) abgelehnt!

Die Konsequenz: Später, schlechter, teurer!

Die Konsequenz daraus lässt sich kurz und knapp mit einem Satz charakterisieren, den mir ein britischer Kollege in einer vergleichbaren Situation sagte:

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
1 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 9
Kommentare 1

Fortsetzungen des Fachartikels

Teil 2:
Pragmatischer Lösungsansatz für Projektmanager
IT-Projektmanager müssen das Dilemma zwischen Notwendigkeit und mangelnder Akzeptanz von Qualitätsmanagement überwinden.

Alle Kommentare (1)

Guest

Ich bin Herrn Schulz dankbar dafür, dass er das Thema offen anschneidet. Wie zu erwarten beleuchtet der Inhalt des Artikels äussertst subjektiv seine Sicht. Erfreulich ist, dass der Autor dies an jeder Stelle des Beitrages deutlich macht. Eingedenk dieser Basis ist besonders der Inhalt des Kapitels "Lösungsansätze ..." irreführend. Durch die Anzahl der Beispiele wird ein Eindruck der Vollständigkeit erweckt. Dieser ist jedoch nicht gegeben und schliesst z.B. die Anteile des agilen PM vollständig aus (obwohl der Autor sich als CSM präsentiert). Auch weist die Literatur zwar auf das Project Excellence Modell hin, seine Ausführungen jedoch nicht. Auch wird auf die eingeführet Arbeitsweise nach dem PDCA für Projekte und speziell für die Abwicklungsgüte in den Projekten nicht abgehoben. Ich bin schon sehr gespannt auf den Teil 2 und erhoffe mir hier einiges von dem angemerkt vermissten zu finden.