Montag Morgen, 8:00 Uhr. Die Anwendung steht und zwar still. Am Freitag Abend wurde die neue Version aufgespielt. Heute Morgen sollte getestet werden. Die Anwendung steht. Der Testmanager Herbert ist nervös, das sieht man ihm an. 10 Anwender, die von entfernten Standorten angereist sind, um die neue Anwendung zu testen, können nicht arbeiten. Irgendwas ist am Freitagabend schief gegangen, das erst am Montag entdeckt wurde. Dabei wurde doch alles genau geplant. Herbert ist ein kluger Kopf, er kennt die Anwendung genau und weiß, was zu tun ist. Er hat einen Plan erstellt und sich genau vorbereitet.
Doch am Montag Morgen ist Herbert hilflos. Der Plan hat nicht geklappt. Schließlich kann der Test doch starten. Die Kollegen haben improvisiert und Zugriff auf einen Testrechner ermöglicht, auf dem normalerweise kein Anwender arbeiten darf. Zwar verspätet, aber ganz erleichtert startet Herbert den Test mit den Anwendern. Der kleine Nachteil der improvisierten Lösung zeigt sich im Laufe des Vormittags. Die Daten, mit denen die Anwendung getestet wird, sind blanker Unfug. Die Anwender sind verärgert. Und vor lauter Ärger monieren sie einen Mangel nach dem anderen. Was eigentlich gar kein Mangel ist, sondern ursprünglich so gewünscht worden war, wird während des Tests flugs ins Gegenteil verkehrt.
Herbert kann sich vor Beschwerden kaum retten. Er muss bei seinem Projektleiter "antreten" und den Verlauf der Tests erklären. Das fällt ihm schwer – schließlich kann er nichts dafür, dass die neue Version nicht zur Verfügung stand. Und das Recht, den Kollegen im Rechenzentrum auf die Sprünge zu helfen hat er schließlich auch nicht. Der Projektleiter ist genervt….
Peter, Testmanager im Nachbar-Projekt hatte neulich ein ganz ähnliches Problem. Peter plant nie besonders genau. Das Aufspielen der neuen Version seiner Software hatte nicht funktioniert. Über Nacht arbeiteten er und sein Team an der Lösung, um den Anwendern am nächsten Tag die versprochenen Funktionen zeigen zu können. Peter hatte bei den Kollegen im Rechenzentrum angerufen, und Hilfe organisiert. Jenseits aller Absprachen, Sicherheitsvorgaben und Pläne, aber es hatte geklappt. Alle waren durchgeschwitzt und müde, aber am nächsten Morgen war der Fehler behoben. Die Freischaltung der Software kann pünktlich erfolgen.
Der Projektleiter hat inzwischen für solche Fälle ein Budget für Extra-Rationen Cola und Pizza.
Mit welchem Testmanager würden Sie lieber zusammen arbeiten? Mit Herbert, der alles akribisch plant und sich auf die Kollegen verlässt? Oder mit Peter, dessen Pläne durchaus auch Lücken aufweisen können, der aber kreative Lösungen findet, wenn es drauf ankommt?
Peter hat immer einen lockeren Spruch auf den Lippen. Aber bei allen flotten Sprüchen merkt man, dass er ein begeisterter Testmanager ist. Bei Herbert ist den Kollegen nicht so ganz klar, wofür er sich begeistert. Er erzählt ja auch wenig. Aber seine Pläne sind immer ganz akribisch.
Was ist das Fazit dieser Geschichte?
In etwa so:
a) Ein Projekt ist ein komplexes, dynamisches System: irgendetwas geht immer schief. Pannen müssen ausgebügelt werden, um doch noch ans Ziel zu kommen. Regeln helfen da oft nur bedingt weiter. Das Zusammenspiel der Beteiligten ist genauso wichtig wie der Rahmen, der durch einen Meilensteinplan oder Termin vorgegeben ist. Manchmal sogar wichtiger.
b) Pläne neigen dazu, sich nicht an die Realität zu halten. D. h. es kommt sehr oft irgendetwas, meistens etwas Banales dazwischen, das niemand vorhergesehen hat. Die beste Planung nutzt nichts, wenn ich mich nur auf den einen Plan verlasse.
c) Es gibt Menschen die kommen damit besser klar als andere. Das hat nichts mit der fachlichen Kompetenz zu tun, wohl aber mit der Leidenschaft, mit der sich der Mensch für ein Thema engagiert und Lösungen abseits des Projektplans sucht.
Doch am Montag Morgen ist Herbert hilflos. Der Plan hat nicht geklappt. Schließlich kann der Test doch starten. Die Kollegen haben improvisiert und Zugriff auf einen Testrechner ermöglicht, auf dem normalerweise kein Anwender arbeiten darf. Zwar verspätet, aber ganz erleichtert startet Herbert den Test mit den Anwendern. Der kleine Nachteil der improvisierten Lösung zeigt sich im Laufe des Vormittags. Die Daten, mit denen die Anwendung getestet wird, sind blanker Unfug. Die Anwender sind verärgert. Und vor lauter Ärger monieren sie einen Mangel nach dem anderen. Was eigentlich gar kein Mangel ist, sondern ursprünglich so gewünscht worden war, wird während des Tests flugs ins Gegenteil verkehrt.
Herbert kann sich vor Beschwerden kaum retten. Er muss bei seinem Projektleiter "antreten" und den Verlauf der Tests erklären. Das fällt ihm schwer – schließlich kann er nichts dafür, dass die neue Version nicht zur Verfügung stand. Und das Recht, den Kollegen im Rechenzentrum auf die Sprünge zu helfen hat er schließlich auch nicht. Der Projektleiter ist genervt….
Peter, Testmanager im Nachbar-Projekt hatte neulich ein ganz ähnliches Problem. Peter plant nie besonders genau. Das Aufspielen der neuen Version seiner Software hatte nicht funktioniert. Über Nacht arbeiteten er und sein Team an der Lösung, um den Anwendern am nächsten Tag die versprochenen Funktionen zeigen zu können. Peter hatte bei den Kollegen im Rechenzentrum angerufen, und Hilfe organisiert. Jenseits aller Absprachen, Sicherheitsvorgaben und Pläne, aber es hatte geklappt. Alle waren durchgeschwitzt und müde, aber am nächsten Morgen war der Fehler behoben. Die Freischaltung der Software kann pünktlich erfolgen.
Der Projektleiter hat inzwischen für solche Fälle ein Budget für Extra-Rationen Cola und Pizza.
Mit welchem Testmanager würden Sie lieber zusammen arbeiten? Mit Herbert, der alles akribisch plant und sich auf die Kollegen verlässt? Oder mit Peter, dessen Pläne durchaus auch Lücken aufweisen können, der aber kreative Lösungen findet, wenn es drauf ankommt?
Peter hat immer einen lockeren Spruch auf den Lippen. Aber bei allen flotten Sprüchen merkt man, dass er ein begeisterter Testmanager ist. Bei Herbert ist den Kollegen nicht so ganz klar, wofür er sich begeistert. Er erzählt ja auch wenig. Aber seine Pläne sind immer ganz akribisch.
Was ist das Fazit dieser Geschichte?
In etwa so:
a) Ein Projekt ist ein komplexes, dynamisches System: irgendetwas geht immer schief. Pannen müssen ausgebügelt werden, um doch noch ans Ziel zu kommen. Regeln helfen da oft nur bedingt weiter. Das Zusammenspiel der Beteiligten ist genauso wichtig wie der Rahmen, der durch einen Meilensteinplan oder Termin vorgegeben ist. Manchmal sogar wichtiger.
b) Pläne neigen dazu, sich nicht an die Realität zu halten. D. h. es kommt sehr oft irgendetwas, meistens etwas Banales dazwischen, das niemand vorhergesehen hat. Die beste Planung nutzt nichts, wenn ich mich nur auf den einen Plan verlasse.
c) Es gibt Menschen die kommen damit besser klar als andere. Das hat nichts mit der fachlichen Kompetenz zu tun, wohl aber mit der Leidenschaft, mit der sich der Mensch für ein Thema engagiert und Lösungen abseits des Projektplans sucht.
