Bereits mit dem Projektstart an das Projektende denken

Zu Beginn eines IT-Projekts gibt es viele Dinge umzusetzen: Projektauftrag fixieren, Stakeholder identifizieren, Risiken analysieren, das Team organisieren, Projekträume besorgen, Arbeitsbedingungen schaffen, Ziele definieren, Organisations- und Kommunikationsstrukturen schaffen ….. oftmals denkt man zu diesem frühen Zeitpunkt aber noch nicht an das Ende des Projekts und die damit verbundene, erfolgreiche Projektabnahme. Viele IT-Projekte beginnen sich erst zu einem sehr späten Zeitpunkt mit dem Thema Abnahme zu beschäftigen – erst wenn diese näher rückt wird über Abnahmekriterien nachgedacht, diskutiert – nicht selten auch zwischen Auftraggeber und Auftragnehmer gestritten.

Als Beispiel aus dem Projektleben: ein lange andauerndes Projekt geht zu Ende – nach langen Jahren der Spezifikation und Bereitstellung von Teillieferungen geht es gegen Ende des Projekts daran, die gesamte Lösung in einer integrierten Testumgebung auf Herz und Nieren zu testen und abzunehmen, sodass eine Produktivstellung erfolgen kann. Das Testmanagement kann dabei auf viele hundert Seiten Spezifikation zurückgreifen, bis hin zu den Anforderungen auf deren Basis das Projekt aufgesetzt wurde. Am Ende der Tests steht eine Abnahme – und hier wird schnell klar: im gesamten Projektverlauf wurden niemals Abnahmekriterien definiert. Sicherlich finden sich in Projektvertrag seitenlange Ergüsse über die Abdeckung der Tests – aber auch das besagt nur, dass die Abnahmekriterien in die Testfälle einfließen müssen – aber was genau sind diese Kriterien? Die Diskussion zwischen Auftragnehmer und Auftraggeber ist vorprogrammiert, als der Auftraggeber beginnt, Kriterien auf Basis vorliegender Spezifikationen und Anforderungen abzuleiten und diese in Testfälle für den Abnahmetest durch den Auftraggeber einzubinden. Und natürlich geht der Auftragnehmer „auf die Barrikaden“ als er die Testfälle vorgelegt bekommt, die zur Abnahme durchgeführt werden sollen.

Hier ist etwas schief gelaufen, was man leider sehr häufig sieht: Zu Beginn eines Projekts wird der Leistungsumfang gemeinsam zwischen Auftraggeber und Auftragnehmer vereinbart. Im Verlauf des Projekts wird dieser dann in Spezifikationen unterschiedlicher Art detailliert und führt gegen Ende des Projekts zu Tests und Abnahmen. Doch erst jetzt wird sich dann im Vorfeld der Abnahme über die hierfür notwendigen Kriterien verständigt. Und dann kommt es zum „A-ha-Erlebnis“: plötzlich stellen Auftraggeber und Auftragnehmer des Projekts fest, dass es da doch noch die ein oder andere Erwartungshaltung „zwischen den Zeilen“ gab, die nicht detailliert genug ausgearbeitet war – nun aber vom Auftraggeber als notwendige Eigenschaft zur Abnahme angesehen wird.

In vielen Projekten werden Abnahmekriterien viel zu spät abgestimmt. Dabei bieten diese Kriterien eine optimale Möglichkeit, die Erwartungshaltungen in einem Projekt abzustimmen und zu fixieren. Damit bilden diese einen wichtigen Meilensteine in der Steuerung von Projekten – und sollten, Ihrer Tragweite geschuldet, so früh wie möglich festgeschrieben werden. Wichtig ist auch, dass diese Kriterien zu den „lebenden Dokumenten“ in einem Projekt gehören: mit jeder weiteren Detaillierung (z.B. durch die Fertigstellung weiterer, detaillierterer Spezifikationen oder im agilen Umfeld nach Abschluss einer weiteren Iteration) sollten die Abnahmekriterien kurz überprüft und ggf. gemeinsam detailliert oder verändert werden. Dies trägt ganz wesentlich dazu bei, dass beide Seiten in einem Projekt (Auftraggeber und Auftragnehmer) jederzeit ein gemeinsames und identisches Verständnis dessen haben, was zum Ende des Projekts geliefert werden wird.

Fazit: Abnahmekriterien sollten frühzeitig, transparent und gezielt dazu eingesetzt werden, um bei allen Stakeholdern die richtigen Erwartungen an die Projektergebnisse sicher zu stellen. Diese Kriterien sind im Verlauf des Projekts regelmäßig gemeinsam zu überprüfen und ggf. fortzuschreiben. Letztendlich können Abnahmekriterien (ähnlich wie die Projektziele) dazu verwendet werden, dem Projektteam sowie den Steuerungsgremien regelmäßig in Erinnerung zu rufen, was die Ergebnisse des gemeinsamen Projekts sein werden bzw. sollen.