Warum führt die Zentrierung auf die Termine so oft zu einer niedrigen Produktvität ?

Die typische Frage bei einem terminzentrierten Ansatz lautet: "Kann der Termin gehalten werden?" Oft lautet die Antwort "Ja, der Termin kann voraussichtlich gehalten werden.", solange auch nur die geringste Hoffnung besteht, dass der Termin gehalten werden kann, selbst wenn schon bekannt ist, dass das Projekt schlecht läuft, die Mitarbeiter auf mehr Probleme stoßen als gedacht, sie sich oft in Warteschleifen befinden, kurz, dass die Produktivität schlecht ist. In diesen Fällen wird beim terminzentrierten Ansatz oft argumentiert, dass es sich um Anfangsschwierigkeiten handelt, die irgendwann verschwinden, oder dass man diese Zeit schon wieder aufholen werde. Da aber die Zeit, die durch schlechte Produktivität verloren wurde, genau dies ist, nämlich verloren, bedeutet dies eigentlich nur, dass man glaubt, dass man irgendwann feststellen wird, dass man es sich leisten konnte, diese Zeit zu verlieren oder genauer gesagt, sie zu verschenken. Allzu oft muss man jedoch am Ende feststellen, dass man sich genau dies nicht leisten konnte.

Die Augen vor den Problemen verschliessen

Selbst wenn schon ernsthafte Zweifel an der Einhaltung des Termins bestehen, wird noch oft bestätigt, dass er gehalten werden kann, dies dann aber an Bedingungen und Annahmen geknüpft, von denen bereits erkennbar ist oder zumindest befürchtet (oder dann auch erhofft) wird, dass sie nicht eintreffen werden. Beispielsweise an die Bedingung, dass andere termingerecht liefern oder sich keine weiteren unvorhergesehenen Probleme stellen werden etc. Und so kommt es, dass oft erst kurz vor dem Termin das ganze Kartenhaus aus Hoffnungen und Annahmen zusammenbricht und erkannt wird, dass der Termin nicht gehalten werden kann, womit sich dann einmal mehr die Regel bestätigt hat, dass, sobald in einem Softwareprojekt angefangen wird, zu hoffen, Enttäuschungen die Folge sind.
Oft werden erst an diesem Punkt die Ursachen für die niedrige Produktivität vom Projektmanagement als Probleme wahrgenommen und als Anlass zum Handeln erkannt. Aber an diesem Punkt ist es meistens schon zu spät, um korrigierend eingreifen zu können.
Selbst wenn die niedrige Produktivität schon vorher erkannt wurde, wird sie oft nicht als Anlass zum Handeln genommen, da ja der Termin vermutlich (oder hoffentlich) trotzdem gehalten werden kann.

Der Versuch, durch Zwischentermine Gewissheit zu erlangen

Oft wird versucht, durch die Einführung von Zwischenterminen oder durch Abfragen von prozentualen Fertigstellungsgraden dieser Probleme Herr zu werden und frühzeitig zu erkennen, ob das Projekt den Zeit- oder Kostenrahmen überschreitet. Aber auch dies schlägt allzu oft fehl.
Das allzu energische Verfolgen der Zwischentermine erweist sich sogar oft als kontraproduktiv, denn in diesem Fall wird häufig mit allen Mitteln versucht, einen Zwischentermin zu halten, selbst um den Preis, dass vorbereitende Tätigkeiten unterlassen werden, die zwar entscheidend für spätere Termine sind, aber eben bedeutungslos für diesen Zwischentermin. Wie weiter unten am Beispiel des Umgangs mit Dokumenten erläutert wird, führt dies oft dazu, dass später Mehraufwände auftreten, die um ein Vielfaches höher sind als die ursprünglich eingesparten Aufwände. Daher steigt der Kosten- und Zeitbedarf für das Projekt und die Gesamtproduktivität wird verringert. Obwohl also das Einhalten des Zwischentermins suggeriert, dass das Projekt auf einem guten Wege ist, ist das Gegenteil der Fall.

Prozentuale Fertigstellungsgrade abfragen

Auch der Versuch, Prozentzahlen für den Fertigstellungsgrad abzufragen schlägt oft fehl. Bei einer Aufgabe, die auf 5 Tage geplant ist, lautet die Antwort nach den ersten 4 Tagen typischerweise 20%, 40%, 60%, 80%. Wer glaubt, dies wäre ein gutes Zeichen dafür, dass der Termin auch nur annährend gehalten werden kann, muss sich in den nächsten Tagen Stück für Stück eines Besseren belehren lassen, denn die Antwort in den nächsten Tagen lautet typischerweise 90%, 95%, 98%, 99%. Falls alles gut läuft, lautet die Antwort am nächsten Tag 100%. Allzu oft lautet die Antwort jedoch, dass die Arbeiten nicht fertiggestellt werden können, da man beispielsweise vorher erst noch Lieferungen von anderen erhalten muss oder weil ein Punkt sich doch nicht wie erhofft lösen lässt. Dies wird auch ausgedrückt durch die Regel "Für die ersten 90% werden 90% der veranschlagten Zeit benötigt. Für die restlichen 10% werden die anderen 90% der Zeit benötigt" [2].

Die Antwort auf die wichtigste Frage

Daher stellt man im Zusammenhang mit dem terminzentrierten Ansatz oft fest, dass die wichtigste Frage der Projektleitung, nämlich die, ob das Projekt termin- und kostengerecht fertiggestellt werden kann, beim terminzentrierten Ansatz nicht mit ausreichender Sicherheit beantwortet werden kann und dass die Antwort "Ja, der Termin kann voraussichtlich gehalten werden" häufig weitgehend bedeutungslos ist.

Beziehung zwischen Soll- und Ist-Terminen

In vielen Projekten gilt die in der linken Abbildung durch die rote Linien beschriebene Beziehung zwischen Soll- und Ist-Terminen. Dabei ist der Soll-Termin der vom Projektmanagement propagierte und als Ziel gesetzte Termin, der Ist-Termin der Termin, zu dem das Projekt wirklich fertig ist. Die blaue Linie würde in dem Fall gelten, dass das Projekt immer genau zu dem Zeitpunkt wirklich fertig ist, an dem es fertig sein soll. Die rote Linie beschreibt den realen Fall. Dass die rote Linie für späte Solltermine (ST H) mit der blauen zusammenfällt, ist Ausdruck der Tatsache, dass Projekte selbst dann, wenn genügend, ja sogar zu viel Zeit gegeben wird, dazu tendieren, nicht vor dem gesetzten Termin fertig zu sein. Wenn man den Soll-Termin dagegen zu knapp setzt (ST L), wird man feststellen, dass es ein gewisses Minimum gibt, unter dem es einfach nicht möglich ist, das Projekt abzuschließen. Dazwischen liegt irgendwo ein optimaler Wert für den Soll-Termin (ST O), bei dem der Ist-Termin zwar etwas höher liegt als beim zu knappen Termin (IT L), aber die Qualität des Ergebnisses besser ist als bei dem zu knappen Termin.

Aus dieser Kurve ergibt sich für das Projektmanagement die Regel, die Termin lieber zu knapp zu setzen, da bei zu weit gesetzten Terminen auch der Fertigstellungstermin sich unnötig hinauszögert. Bei zu knapp gesetzten Terminen dagegen besteht lediglich das Risiko, dass die Qualität der Arbeit nicht ausreichend ist, was man aber oft leicht nachbessern kann.

Aufgrund der oben erläuterten Zusammenhänge gilt für Softwareprojekte allerdings eine andere Kurve, die in der rechten Abbildung dargestellt ist. Für zu großzügig gesetzte Soll-Termine gilt wieder, dass der Ist-Termin diesen folgt. Es gibt einen optimalen Soll-Termin (ST O), bei dem das Projekt zum frühest möglichen Zeitpunkt fertig ist (IT O). Aber für zu eng gesetzte Termine (z.B. ST L) gilt diesmal der Effekt, dass der Ist-Termin (IS L) dramatisch ansteigt. Daraus ergibt sich als Regel für das Projektmanagement, dass es in Softwareprojekten sehr gefährlich ist, einen Soll-Termin zu nennen, der früher als der optimale Soll-Termin liegt, da dies nicht, wie in vielen Projekten sonst, dazu führt, dass das Projekt früher fertig ist, sondern im Gegenteil dazu führt, dass das Projekt aufgrund der oben beschriebenen Effekte sehr viel später fertig wird.

Zurück zur Übersichtsseite