Sondereinsätze in der IT
Den Absturz verhindern
Weniger Führungskräfte, mehr Erfolg
Die Erklärung für diese empirisch ermittelte Erkenntnis lässt sich auch auf ein anderes Gesetz zurückführen, das den Namen des IBM-Entwicklers Frederick Brooks trägt: Mit zunehmender Größe eines Projektteams steigt danach der Koordinations- und Kommunikationsaufwand überproportional an. Brooks fand dies in den 60erJahren heraus, als er bei IBMIBM für die Entwicklung der Großrechnersysteme vom Typ 360 zuständig war. Heilmann empfiehlt den Betroffenen, sich an dieses Gesetz zu erinnern, wenn sie in der Endphase eines Projekts das Team vergrößern wollen, um den Zeitplan noch einzuhalten: "Der Fortschritt tendiert gegen null, wenn die bisherigen Projektbeteiligten die neuen ein-arbeiten und dazu ihre Tätigkeit unterbrechen müssen."
Alles zu IBM auf CIO.de
Und noch ein Grundsatz hält die Stuttgarter Professorin (im Ruhestand) für Projektleiter parat: Nach C. Northcote Parkinson nimmt sich jeder Mensch für eine Arbeit so viel Zeit, wie er zur Verfügung hat. Der britische Beamte Parkinson formulierte diese Erkenntnis, nachdem er eine Weile den Niedergang des British Empire beobachtet hatte und gleichzeitig die Zahl der Angestellten in der Kolonialbehörde wachsen sah. Laut Heilmann trifft Parkinson’s Law auch auf die Arbeit an IT-Projekten zu: "Gibt man Menschen zu lockere Termine, neigen sie dazu, unnötig perfektionistisch oder weniger intensiv zu arbeiten." Zugleich warnt sie: "Regelmäßige Überstunden über einen längeren Zeitraum reduzieren die Mitarbeitermotivation. Unter keinen Umständen dürfen sie von vornherein in die Terminplanung einbezogen werden."
Neun von zehn Projekten verändern sich
Zwar fehlt hier noch ein schöner Name, aber in der Welt der IT-Projekte könnte noch ein anderes Gesetz postuliert werden: Caper Jones, Chef-Forscher beim PM-Software-Anbieter Artemis, hat herausgefunden, dass sich in 90 Prozent aller Fälle die Anforderungen während der Projektlaufzeit verändern. Um dieses Problem zu begrenzen, rät er, IT-Lösungen gemeinsam mit den End-benutzern zu entwickeln, wodurch sich die Hälfte der Änderungswünsche eliminieren lasse. Prototypen könnten weitere 10 bis 25 Prozent der Änderungen in eine frühe Phase verlagern. Für große Projekte empfiehlt Jones so genannte Change Control Boards aus Management, Benutzerrepräsentanten und Entwicklern.
Letztlich ist es also die Kommunikation der beteiligten Parteien, die über den Erfolg eines Projekts entscheidet. "Sie müssen Zwischentöne hören können", sagt Karin-Beate Elbrechter, die fünf Jahre Projekt-Controlling bei der Commerzbank betrieben hat. "Es liegt nicht an Beratern oder Werkzeugen. Da können sie MS-Projects, Excel oder ein Schmierblatt nehmen." Wichtiger sei, dass sich alle Beteiligten immer wieder über die Ziele abstimmen, über Projektrisiken offen sprechen und konkrete Maßnahmen einleiten. Nur so lasse sich verhindern, was Elbrechter ihre wichtigste Erfahrung in puncto Kostentreiber nennt und was in vielen Unternehmen gängige Praxis ist: "Projekte werden grün geredet. Sie scheitern per Definition nicht, weil die Budgets immer angepasst werden."