Testmanagement in Klinikprojekten: Der unterschätzte Hebel für Projekterfolg – nicht nur für den Go-Live

Und sobald dieser Begriff fällt – sei es in der Projektleitung, im Lenkungskreis oder im Projektteam – verändert sich die Stimmung.

Nicht dramatisch. Aber spürbar.

„Ja, da schauen wir dann, wie weit wir sind…“

„Das hängt ja auch davon ab, wie viel noch offen ist…“

„Die Key User haben eh kaum Zeit – wir müssen das irgendwie pragmatisch lösen…“

Es ist kein offener Widerstand, kein kategorisches Nein.

Aber es ist auch kein klares Ja.

Es ist dieses typische Ausweichen, das man aus überfüllten Kalendern, knappen Ressourcen und der realen Projektmüdigkeit gut kennt. Und das ist verständlich. Wirklich.

Denn wer mitten in der Anforderungsflut, der Abstimmung mit dem Hersteller und der Absicherung von Betriebsübergängen steckt, für den klingt eine strukturierte Testphase erstmal nach zusätzlicher Last – nach noch mehr Koordination, nach Rückmeldungen, auf die jemand reagieren muss, nach unklaren Verantwortlichkeiten und der berechtigten Sorge: „Wenn wir jetzt alle Fehler kennen – können wir die überhaupt noch beheben?“

Ich kenne diese Gedanken.

Ich habe sie in unzähligen Projekten erlebt – in Gesprächen, in Nebensätzen, manchmal unausgesprochen. Und ich halte sie für berechtigt.

Denn Testmanagement ist kein Nebenbei-Thema. Es fordert Zeit, Aufmerksamkeit, Konzentration. Es fordert Klarheit. Und Mut zur Lücke.

Aber: Genau deshalb lohnt es sich, diesen Punkt nicht zu vertagen, sondern ihn sehr bewusst anzuschauen – nicht als technisches Element am Ende der Projektkette, sondern als Schlüsselstelle, an der sich entscheidet, ob ein Projekt tragfähig ist. Für den Betrieb. Für die Menschen. Und für den Anspruch, den wir an unsere Arbeit stellen.

In vielen Projekten wird über Monate hinweg geplant, entschieden, konfiguriert und abgestimmt. Man steckt tief drin im Aufbau – in Modulen, Rollen, Formularen, Prozessen, Freigaben. Man schließt Teilaufgaben ab, füllt Listen, dokumentiert Anforderungen, hält Meilensteine ein. Und mit jedem Schritt steigt das Bedürfnis nach Fortschritt, nach Ergebnissen, nach Haken an den offenen Punkten.

Was dabei oft zu kurz kommt – oder schlicht verschoben wird – ist das, was eigentlich mehr Sicherheit geben soll: die strukturierte Testphase.

Nicht, weil sie nicht vorgesehen wäre. Sie steht in fast jedem Projektplan. Aber sie wird in der Praxis häufig nach hinten geschoben, unter Zeitdruck verkürzt oder nur teilweise umgesetzt.

Nicht aus Ignoranz. Sondern weil in genau dieser Projektphase der Druck am höchsten ist.

Der Gedanke ist nachvollziehbar: Wir müssen erstmal fertig werden – dann schauen wir.

Was oft nicht bedacht wird: Gerade dann wird es schwierig.

Denn in der Testphase geht es nicht darum, ob etwas grundsätzlich eingerichtet wurde – sondern ob es funktioniert, im Ablauf, in der Nutzung, in der Abstimmung mit anderen.

Und genau das zeigt sich nicht in Excel oder auf PowerPoint-Folien. Sondern im Zusammenspiel aller Bereich im Alltag.

Ich erlebe häufig, dass das Testen unterschätzt wird – oder sehr technisch verstanden wird: als letzter Check vor dem Go-Live. Als Kontrollschleife. Oder als Extraaufgabe.

Dabei ist es genau andersherum:

Die Testphase ist der Moment, in dem das Projekt greifbar wird.

In dem man erkennt, wie Prozesse tatsächlich ablaufen.

Und in dem sichtbar wird, ob alles, was bisher geplant wurde, auch tragfähig ist.

Eine gut organisierte Testphase zeigt nicht nur, ob eine Software funktioniert – sie zeigt, ob das Projekt als Ganzes verstanden wurde. Denn in diesem Moment treffen erstmals alle Konfigurationen, Rollen, Abläufe und Systemlogiken auf die reale Anwendung durch die Menschen, für die sie gedacht sind.

Im Test entstehen keine neuen Anforderungen – sie treten lediglich zutage.

Oft zeigt sich erst dann, ob die Dokumentation in der Pflege logisch anschließt, ob eine Arztrolle Zugriff auf alle Inhalte hat, ob eine Leistung korrekt in der Abrechnung ankommt oder ob ein interdisziplinärer Verlauf durchgängig nutzbar ist.

Und weil in Projekten alle Bereiche einen gewissen Stand der Fertigstellung erreicht haben müssen, ist die Testphase oft der einzige strukturierte Zeitraum, in dem diese Fragen gestellt – und beantwortet – werden können.

Was in diesem Moment auffällt, ist dabei nicht nur technisch relevant – es ist organisationale Realität:

Ich beobachte immer wieder, dass die größten Erkenntnisse in der Testphase nicht auf technischer Ebene stattfinden – sondern auf der Ebene des Verständnisses:

Diese Erkenntnisse lassen sich nicht beliebig verschieben.

Sie treten nicht irgendwann später „automatisch“ auf.

Sie entstehen nur dann, wenn Zeit, Struktur und Beteiligung zusammenkommen.

Und genau das leistet eine gut vorbereitete Testphase.

Wenn ich mit Projektleitenden oder IT-Verantwortlichen spreche, höre ich immer wieder ähnliche Fragen, sobald es um die Testphase geht:

Wer soll das alles testen – unsere Leute sind ohnehin überlastet.

Wie sollen wir all das Feedback verarbeiten – und vor allem rechtzeitig?

Was machen wir, wenn gar nichts zurückkommt – oder viel zu viel auf einmal?

Diese Fragen sind berechtigt.

In den meisten Projekten ist die personelle Belastung ohnehin hoch, viele Key User sind in Doppelrollen unterwegs, neben der Projektarbeit läuft der Klinikalltag weiter – und der Gedanke, nun auch noch eine systematische Testphase umzusetzen, wirkt auf den ersten Blick nicht realistisch.

Ich verstehe das sehr gut.

Denn die Sorge dahinter ist real:

Was, wenn wir mit dem Test nur zusätzliche Komplexität erzeugen – ohne den nötigen Handlungsspielraum, um etwas daraus zu machen?

Und trotzdem: Diese Bedenken lassen sich nicht lösen, indem man das Testen minimiert oder auf einzelne Teilprojekte delegiert.

Denn die Fragen, die dort unbeantwortet bleiben, tauchen spätestens im Echtbetrieb wieder auf – mit dem Unterschied, dass sie dann nicht mehr auf einer Testumgebung aufschlagen, sondern im realen Versorgungsgeschehen.

Was sich also wie eine „Entlastung“ anfühlt – die Tests kürzen, auf ein Kernteam reduzieren, auf das Wesentliche beschränken –, verschiebt den Aufwand nur.

Und das mit höheren Risiken, weil Fehler, Lücken oder Missverständnisse dann unter Live-Bedingungen sichtbar werden – häufig zu einem Zeitpunkt, an dem kaum noch jemand Kapazitäten hat, um strukturiert nachzubessern.

Deshalb ist mein Vorschlag nicht: mehr Aufwand betreiben – sondern: früher klar definieren, was in welcher Tiefe wirklich gebraucht wird.

Wenn das frühzeitig strukturiert ist, wird das Testen nicht zur Überforderung, sondern zur Absicherung.

Und genau das ist der eigentliche Gewinn.

Ein Testkonzept muss nicht perfekt sein. Es muss auch nicht jeden Spezialfall im Voraus erfassen oder alle potenziellen Fehlerquellen eliminieren.

Was es leisten muss, ist etwas anderes – und zugleich Entscheidendes: Es muss die Testphase so strukturieren, dass sie im Alltag machbar bleibt – und trotzdem wirksam ist.

Dazu gehört zunächst, den Fokus richtig zu setzen:

Nicht alles gleichzeitig und überall, sondern priorisiert nach dem Pareto-Prinzip: Die 80 %, die tagtäglich passieren, müssen sauber durchlaufen.

Die Sonderkonstellationen – also die restlichen 20 % – können nachgezogen werden, wenn dafür noch Kapazitäten bleiben oder wenn sie sich in der Anwendung als kritisch herausstellen.

Ein gutes Testkonzept gibt Orientierung, ohne zu viel vorzugeben.

Es benennt Rollen und Verantwortlichkeiten, definiert Kommunikationswege, schlägt Formate vor – und lässt Raum für projekt- oder hausspezifische Besonderheiten.

Es beantwortet Fragen wie:

Und es verhindert, dass Testen zur „Privatsache“ einzelner Projektbeteiligter wird – sei es durch punktuelle Rückmeldungen per E-Mail, durch Einzeltests im Tagesgeschäft oder durch Excel-Listen, die niemand sauber auswertet.

Stattdessen schafft es eine gemeinsame Struktur – die nicht mehr verspricht, als leistbar ist, aber deutlich mehr absichert, als ein „Wir schauen dann mal“-Vorgehen.