Moving Targets im Projekt-Management

Ein Projektleiter muss sich auf Änderungen freuen

26.07.2012
Von Marc Voland
Ziele und Anforderungen ändern sich immer wieder im Laufe eines Projektes. Moving Targets zu erkennen, gehört zu den Grundaufgaben eines Projektleiters. Wichtigste Regel: kommunizieren.
Unvorhersehbare Richtungswechsel gehören zum Alltag eines Projektleiters.
Unvorhersehbare Richtungswechsel gehören zum Alltag eines Projektleiters.
Foto: Alexey Rozhanovsky _shutterstock

Er hätte die Warnsignale früher erkennen müssen. Das ist Peter B. im Nachhinein klar. Als der IT-Projektleiter und sein Team Key Usern die erste Leistungsstufe präsentierte, begann eine stundenlange Fachdiskussion. Dabei hatte man sich doch getroffen, um die Qualität der CRM-Software zu beurteilen. Für das nächste Mal weiß Peter B.: Schon vor dieser Präsentation hätten sie gemeinsam die festgelegten Ziele überprüfen müssen. Fortan besprach er die Anforderungen und Wünsche der Anwender immer anhand eines Prototyps und überarbeitete regelmäßig die Ziele, so dass er das ambitionierte Projekt doch noch erfolgreich abschließen konnte.

Dass Projekte scheitern, hat vielfältige Gründe. Für Stefan Rauch, Projektleiter beim IT-Dienstleister Iteratec, fällt einer besonders ins Gewicht: "Wenn sich im Laufe des Projektes die Anforderungen ändern, kann das zu ernsten Komplikationen führen." Bestätigt wird seine Erfahrung durch eine Studie der Beratung Roland Berger, die diesen Umstand sogar als Hauptrisikotreiber bei IT-Großprojekten ausmachte. Die beim Start dokumentierten Anforderungen und Spezifikationen an das IT-System sind das eine, die Realität in den Unternehmen oft eine andere. Ob man es Scope Creep oder Moving Target nennt: "Bei nahezu allen Projekten ändern sich die ursprünglich vereinbarten Ziele", sagt Stefan Rauch. Am offensichtlichsten sind Änderungen der Gesetzeslage - seien es Zollbestimmungen, Kennzeichnungspflichten oder neue Dokumentationsstandards, die im laufenden Projekt nachgezogen werden müssen. Oft ist es auch die Technologie, die eine Korrektur der Ziele nötig macht. Vor allem bei Pionier-Projekten, die mit Leading-Edge-Technologie arbeiten, zeigt sich häufig erst im Laufe der Entwicklung, welche zusätzlichen Wege sich eröffnen. Neue Anforderungen kommen auch aus dem Unternehmen selbst, etwa wenn eine neue Verkaufsstrategie in die IT übersetzt werden muss.

Sprachliche Stolpersteine

Stefan Rauch, Iteratec: "Die Fußangeln bei Projekten sind oft einfach sprachliche Ungenauigkeiten."
Stefan Rauch, Iteratec: "Die Fußangeln bei Projekten sind oft einfach sprachliche Ungenauigkeiten."
Foto: Iteratec

"Mit solchen Änderungen kann man umgehen, denn sie sind für alle Beteiligten klar und nachvollziehbar. Richtig hinterhältig sind aber die versteckten Annahmen, die in das Projekt hineininterpretiert werden", sagt Rauch, der allen Projektleitern rät, diese so schnell wie möglich aufzuspüren. Oft bestehen die Fußangeln aber nicht in mangelnder fachlicher Logik oder inhaltlicher Kompetenz, sondern schlicht in sprachlicher Ungenauigkeit. Beispielsweise in der Fachspezifikation. Steht dort etwa der Passus "Das System muss performant sein", müssen sofort alle Alarmglocken angehen. "In einem solchen Fall sollte der Projektleiter möglichst schnell klären, was "performant" bedeutet. Ähnliche Stolpersteine sind Formulierungen wie "das System soll flexibel konfigurierbar sein", oder "der Funktionsumfang soll dem des Altsystems entsprechen".

Damit Auftraggeber und Auftragnehmer möglichst schnell abgleichen können, ob die Anforderungen richtig verstanden wurden, bietet sich ein früher Prototyp an. Dieser muss nicht den vollen Funktionsumfang aufweisen, in manchen Fällen reicht sogar ein Screenshot, um dem Kunden das User Interface zu zeigen. Im zweiten Schritt kommt der tiefe technische Durchstich. Eine "kleine Funktionalität" wird eingeführt, die sich durch alle Schichten der Softwarearchitektur zieht. Ist ihre grundsätzliche technische Machbarkeit belegt, werden die anderen Funktionalitäten implementiert.

Projekterfolg durch agile Softwareentwicklung

Ein Beispiel für dieses Vorgehen ist das Carsharing Projekt DriveNow von BMW und Sixt. Das Team des IT-Dienstleisters Iteratec hat sich mit den Verantwortlichen auf Kundenseite immer wieder abgestimmt, der Planunghorizont war kurz, Ergebnisse und Ziele wurden immer wieder reflektiert und angepasst. Dadurch konnte in sehr kurzer Zeit eine Lösung in Betrieb genommen werden, die auch auf die zu Projektbeginn nicht absehbaren technischen Möglichkeiten und Schwierigkeiten reagieren konnte. Iteratec-Projektleiter Rauch und BMW-Projektleiter Bernhard Stimpfle sind sich hier einig, dass das agile und gemeinschaftliche Vorgehen maßgeblich zum Projekterfolg beigetragen hat. Für Stimpfle stehen "die Iterationsschleifen in einem Projekt in Relation zum resultierenden Produkt: "Entwicklung von Mobilitätsdienstleistungen erfordern daher besonders kurze Sprints."

Wer die Prinzipien der iterativen und agilen Softwareentwicklung berücksichtigt, hat die größtmögliche Kontrolle über das Projekt und seine Ziele, ist Rauch überzeugt. Entwickler, die nach dem Wasserfallmodell vorgehen, haben es aus seiner Sicht deutlich schwerer. "Bei diesem Vorgehen verständigt man sich auf ein festes Ziel und hält an diesem möglichst bis zum Ende fest. Im Rahmen eines solchen Projektes, das Entwicklungsabschnitte von sechs Monaten und mehr kennt, ist es psychologisch schwerer, auf Änderungen einzugehen."