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: