Der Auftraggeber eines neuen Softwareprojekts hat die erste Hürde genommen: er hat einen Dienstleister gefunden, der es umsetzen wird. Alle Beteiligten sind zunächst bester Stimmung:

• Der Kunde (Auftraggeber) hat einen qualifizierten Dienstleister gewonnen und zählt nun darauf, dass dieser seine Erwartungen im Zeit- und Kostenrahmen umsetzen wird.
• Der Vertrieb und die Geschäftsführung des Dienstleisters freuen sich über den neuen Auftrag, dessen Mehrwert sie bereits einplanen und kommunizieren können.
• Der Projektleiter des Dienstleisters sieht das neue Projekt als nächsten Schritt für seine Karriere und will zeigen, was er kann.
• Das Entwicklungsteam ist motiviert, eine ebenso herausfordernde wie interessante Aufgabe anzugehen.

Das Testteam und die Qualitätssicherung sehen die Situation in der Regel neutral: Für sie ist ein Softwareprojekt "business as usual". Ihr Ziel ist es zu gewährleisten, dass eine wartungsfähige Software erstellt wird, die gleichermaßen den selbst gesteckten Ansprüchen des Auftragnehmers wie auch den Qualitätserwartungen des Kunden entspricht.

Der Kunde und das Management des Dienstleisters erwarten, dass die Arbeit für sie nun im Wesentlichen getan ist und sie ab jetzt alle weiteren Aufgaben bloß noch zu delegieren brauchen. Allerdings haben sie im Hinterkopf jeweils diametral entgegengesetzte Vorstellungen über die von nun an entstehenden Aufwände: Während der Auftraggeber davon ausgeht, dass mit dem vereinbarten Preis all seine Erwartungen erfüllt werden, nimmt der Auftragnehmer an, dass der Kunde eventuell entstehende Mehraufwände, u.a. für eine bessere Qualität, tragen wird.

Projektleiter (PL) und Entwickler scheinen sich völlig einig zu sein und gehen gemeinsam die Aufgabe mit voller Energie an. Spannungen zwischen diesen beiden Rollen entstehen erst im Verlauf des Projekts. Ursache hierfür sind die Schnittstellen zum Kunden und zum Management des Auftragnehmers, für die der Projektleiter verantwortlich ist. Erfahrungsgemäß entwickeln sich die Vorstellungen dieser Stakeholdergruppen mit zunehmender Projektdauer immer weiter auseinander. Der Projektleiter hat dann die Aufgabe, zwischen diesen Interessenskonflikten hinsichtlich Budget, Qualität und Termin zu vermitteln. Diesen Druck gibt er oftmals an das Entwicklungsteam weiter mit den typischen Fragen: "Wieso braucht Ihr so lange? Warum sind so viele Fehler im Code? Wann werdet Ihr endlich fertig?"

Eine Schlüsselstellung nimmt dabei die Abteilung für Qualitätssicherung und Tests ein – falls es sie tatsächlich gibt. Je nach Projektorganisation und Reifegrad der beteiligten Unternehmen werden Qualitätsüberwachung und Tests von eigens dafür qualifizierten Mitarbeitern und Organisationseinheiten durchgeführt oder eher unsystematisch an Mitarbeiter vergeben, die gerade freie Kapazitäten haben. Qualitätsüberwachung und Tests entscheiden aber darüber, ob ein erstelltes Modul oder die gesamte Software abgenommen wird. Und obwohl die Mitarbeiter der Qualitätssicherung und die Tester, unabhängig von ihrer organisatorischen Zuordnung, dem Projekt gegenüber neutral eingestellt sind, geraten Sie sehr schnell mitten in die Konfliktlinien. Beispiele für häufig anzutreffende Vorwürfe an Qualitätsverantwortliche sind:

Viele Entwickler haben Vorbehalte gegenüber professionell durchgeführtem Qualitätsmanagement, da dieses in ihren Augen unerfüllbar hohe Ansprüche (meist hinsichtlich Aufwand) an Fehlerfreiheit und Testverfahren stellt.

• Auftraggeber werfen Qualitätsverantwortlichen vor, wesentliche Fehler nicht erkannt zu haben.
• Das Management des Auftragnehmers ist ungehalten darüber, dass Qualitätsprüfungen Geld und Zeit kosten.
• Der Projektleiter ärgert sich, wenn die Qualitätssicherung aufgrund eines scheinbar geringfügigen Mangels keine Freigabe für ein Modul erteilt.

Obwohl der hier beschriebene Effekt weit verbreitet ist, finden sich in den Lehrbüchern für Projektmanagement keine wirksamen Lösungsansätze, um diese vorhersehbaren Konflikte zu vermeiden oder zumindest zu mindern. So beschreibt der PMBOK® Guide im Wissensgebiet "Qualitätsmanagement in Projekten" zwar immerhin die drei Projektmanagementprozesse "Qualität planen", "Qualitätssicherung durchführen" und "Qualitätslenkung durchführen". Wie dies aber bei einem konkreten Projekt mit unterschiedlichen Erwartungshaltungen der Beteiligten umgesetzt werden kann, findet der Projektleiter dort nicht. Grund dafür ist natürlich, dass Richtlinien und Standards für Projektmanagement für alle Arten von Projekten gelten sollen, die operative Ausgestaltung des Qualitätsmanagements aber stark vom Projektgegenstand abhängt.

Breiten Raum widmen PM-Richtlinien völlig zu Recht der genauen Spezifikation des Projektergebnisses. Dabei wird aber übersehen, dass die Projektergebnisse auch hinsichtlich ihrer Übereinstimmung mit der Spezifikation geprüft werden müssen. Hierfür ist die Qualitätssicherung zuständig. Meiner Erfahrung nach wird aber der konkreten Ausgestaltung der Qualitätssicherung, d.h. der Qualitätsüberwachung und der Durchführung von Qualitätsprüfungen, zu wenig Beachtung geschenkt.