Softwareentwicklung
Kein Programm läuft so rund wie das andere
Auch die Festnetztochter der Deutschen Telekom, T.Com, nutzt FPA als Methode, und zwar zur Steuerung ihrer Software-Entwicklungspartner, die mit knapp 1400 Mitarbeitern in zirka 180 Projekten pro Jahr tätig sind. Das Ziel, so Ulrich Völkoi aus dem Bereich Informationsmanagement und Prozesse: die IT-Projekte im „magischen Dreieck“ von Kosten, Zeit und Qualität optimieren. Sowohl intern als auch extern wird verglichen: intern etwa die Anzahl der Änderungsanforderungen aus den Fachbereichen, die Anzahl der verschobenen Termine und die Fehlerzahl in der Software. Externe Vergleiche anhand von Function Points beziehen sich unter anderem auf Produktität (FP pro Personenmonat) und Stückkosten je Function Point. Laut Völkoi hat T.Com mit diesem Verfahren „signifikante Einsparungen“ realisiert.
Vielleicht kommt es auch gar nicht so sehr darauf an, welches Verfahren man im Entwicklungs-Controlling anwendet. Allein das Bewusstsein bei den Entwicklern, beobachtet zu werden, kann nämlich eine Produktivitätssteigerung bewirken. Schon in den zwanziger Jahren des letzten Jahrhunderts hat der US-Psychologe Elton Mayo genau diesen Effekt nachgewiesen. Im Werk Hawthorne von Western Electric studierte er fünf Jahre lang Arbeiter. Allein dadurch, dass sie unter Kontrolle standen und das auch wussten, waren die beobachteten Western-Electric-Worker produktiver als ihre Kollegen, auf deren Arbeit man kein so scharfes Auge warf. Poensgen ist überzeugt, dass dieser Effekt (Volksmund: „Das Auge des Herrn macht das Vieh fett.“) sich auch bei der Softwareentwicklung einstellt.
Plädoyer für realistische Zeitpläne
Man sollte allerdings aufpassen, dass die Planer und Akteure in der Softwareentwicklung es mit dem Eifer nicht übertreiben, meint Falk Janotta, Interims-Projektmanager aus Wilhelmshaven. Wenn nämlich bereits in der Planungsphase enge Zeitvorgaben akzeptiert würden, um auch ja mit guten Kennzahlen in ein Projekt einzusteigen, seien Projektverantwortliche von Anfang an in der Defensive. Häufig bleibe noch nicht einmal genug Zeit, ein Projekt seriös durchzuplanen und dann mit der Geschäftsleitung oder der Fachabteilung über eine realistische Projektstruktur und damit einen realistischen Zeit- und Kostenplan zu reden.
Janotta lehnt Benchmarking in der Softwareentwicklung nicht ab. Um mehr Qualität und einen höheren Wertbeitrag der Software zu erreichen, plädiert er, sei jedoch etwas anderes vordringlich: „weniger Zeitdruck, kleinere Einheiten und mehr Aufwand für Analyse, Konzeption und Spezifikation von Projekten“.