Was bestimmt den tatsächlichen Aufwand eines IT-Projektes?

IT‑Projekte werden regelmäßig dafür kritisiert, dass die Budgets nicht eingehalten werden. Grundlage der Budgetierung sind mehr oder minder professionell durchgeführte Aufwandschätzungen. Wer immer von sich behaupten könnte, zuverlässige Aufwandschätzungen erstellen zu können, hätte eine große Nachfrage gewiss. Wie könnte das gelingen?

Eine Methode zur Aufwandsschätzung mit langer Tradition sind Function Points. Sie wurde in den siebziger Jahren in den IBM Labors entwickelt, um schon relativ früh den voraussichtlichen Aufwand einer Software-Entwicklung abschätzen zu können.

Function Points bilden die funktionalen Anforderungen der Anwender ab und leiten daraus den voraussichtlichen Entwicklungsaufwand ab, noch bevor die detaillierte technische Analyse und Planung stattgefunden hat. Als die Methode entwickelt wurde, herrschten allerdings vergleichsweise einfache Rahmenbedingungen. Es ging grundsätzlich um Individualentwicklung, weil das Angebot an Standardsoftware noch sehr gering war. Die Anzahl der zur Verfügung stehenden Entwicklungsumgebungen war ebenfalls überschaubar, im Falle IBM damals COBOL oder PL1. Aber selbst unter den damals herrschenden sehr einfachen Rahmenbedingungen gibt es in der Schätzmethodik einen sehr weichen Parameter, der das Skillniveau der Entwickler berücksichtigt. Die Herausforderung einer zuverlässigen Aufwandschätzung ist heute ungleich komplexer.

Letztlich folgen alle Ermittlungsmethoden dem Muster der Function-Point-Methodik. Die COCOMO-Methode geht einen Schritt weiter in Richtung Realisierung und berücksichtigt die Produktivität der gewählten Entwicklungsplattform. Story Points in der agilen Welt ordnen den User Stories (letztlich wenig formalisierte Use Cases) eine relative Maßzahl für den Aufwand zu, verzichten aber auf eine explizite Umrechnung in Aufwand. Kennt man allerdings einmal die „Velocity“ des Teams, ist die Umrechnung der Story Points in Aufwand eine einfache Übung und nur aus ideologischen Gründen bei Dogmatikern der Agilität verpönt.

Welche Faktoren entscheiden heute – die funktionalen Anforderungen stehen natürlich weiterhin an erster Stelle – über den Aufwand der Realisierung bis zum erfolgreichen Einsatz?

Hier eine Liste:

• Die funktionalen Anforderungen der Anwender
• Der Funktionsumfang verfügbarer Standard‑Software
• Der Mix von Standardsoftware, Reuse vorhandener Software und Individualentwicklung
• Die Architektur der eingesetzten Standard‑Software oder die Architektur der eigenentwickelten Lösung
• Die nicht‑funktionalen Anforderungen wie zum Beispiel Safety, Security, Performance und Usability
• Die Qualifikation der beteiligten Personen (insbesondere Management, Projektleiter, Geschäftsprozessanalytiker, Softwareentwickler u.a.)
• Die Qualität der Projektabwicklung (angemessene Granularität der Planung, Projektleitung und Projektcontrolling etc.)
• Die Verfügbarkeit geeigneter Personen für die zu besetzenden Projektfunktionen
• Die Effizienz der Zusammenarbeit im Projekt
• Nicht vorhersehbare Einflüsse, wie zum Beispiel Krankenstände, Kündigungen oder auch technische Probleme
• Die Mikroorganisation der Projektarbeit (Priorisierung, Vermeiden von Multitasking, Termindisziplin, Urlaubsplanung etc.)
• Die Vielfalt und Komplexität der Voraussetzungen für den Rollout, z.B. in verschiedenen Unternehmen eines weltweit agierenden Konzerns oder auch nur in verschiedenen Abteilungen eines Unternehmens.

Die Vielfalt der einwirkenden Faktoren – und die Liste ist bei weitem nicht vollständig – macht klar, dass eine zuverlässige Aufwandschätzung vor dem Start eines Projektes nicht möglich ist. Das spricht nicht gegen das Durchführen einer Aufwandschätzung, diese ist immer notwendig und unabdingbar. Man darf nur hinsichtlich des Ergebnisses nicht vergessen, dass es eine Schätzung unter gewissen Annahmen ist. Da Abweichungen von den ursprünglichen Annahmen fast immer zu einer Erhöhung, nur sehr selten aber zu einer Verringerung des Aufwandes führen, muss ein ausreichender Aufwandspuffer eingeplant werden. Tut man das nicht, bringt man das Projekt in zusätzliche Schwierigkeiten: für notwendige Arbeiten stehen nicht genügend interne Kräfte zur Verfügung oder die notwendigen externen Ressourcen dafür können nicht zugekauft werden. Der Aufwand steigt dadurch letztlich noch mehr als ohnehin unvermeidbar gewesen wäre.

Anzumerken ist auch, dass es hier um Aufwand sowohl in Form von Personentagen als auch in Geld geht. Der Ankauf von Software substituiert Personalaufwand. Externe Projektmitarbeiterinnen und -mitarbeiter schlagen sich ebenfalls im finanziellen Aufwand nieder. Hingegen werden die internen Mitarbeiterinnen und Mitarbeiter häufig als „eh schon da“-Kosten nicht gesondert geplant und controllt. Wenn im Verlauf eines Projektes der Einsatz zusätzlicher externer Personen notwendig wird, läuft das Budget weitaus schmerzhafter aus dem Ruder als wenn „nur“ die internen Ressourcen vom Mehraufwand betroffen sind. Man sieht also, dass eine Aufwandschätzung, die das eigentliche Anliegen des Managements – Planungssicherheit – befriedigen will, eine sehr komplexe Angelegenheit ist. Nicht zuletzt wirkt auch der Mechanismus der self-fulfilling- oder auch der selfdestroying-prophecy, je nach Motivations- und Interessenslage der Beteiligten. So sehr man Ehrlichkeit und Offenheit als kulturellen Wert schätzen sollte, kann die offene Kommunikation der Budgetreserven und möglicher Fallback-Termine dazu führen, dass diese Reserven auch tatsächlich in Anspruch genommen werden.

Man kann es pointiert formulieren: Jede Aufwandschätzung ist falsch, wir wissen nur nicht wie und warum!

Und: Es kommt nicht darauf an, den Aufwand richtig zu schätzen, es geht darum, ihn zu minimieren!