Vorgehen zur Schätzung von IT Entwicklungs-Projekten

Seit vielen Jahren erstelle ich in der Rolle als Software Architekt Schätzungen für Angebote von Entwicklungsprojekten. Dies ist meiner Meinung nach eine der schwierigsten und verantwortungsvollsten, aber auch oft unterschätzten Aufgaben des Projektgeschäfts. Die Schätzung sollte im Eigeninteresse möglichst präzise ausfallen. Sie legt den Grundstein für jedes Projekt. Ist die Schätzung zu niedrig angesetzt, dann wird das Projekt früher oder später in Zeit- und Budgetnot geraten. Wird sie zu hoch angesetzt, dann kann der Zuschlag für den Auftrag an die Konkurrenz gehen. Ist der Lösungsansatz falsch gewählt, das technische Know How im Implementierungsteam nicht verfügbar oder die Risiken sind nicht berücksichtigt, dann verringert sich der Projekterfolg in der Umsetzung. Meiner Meinung nach hängt ein Großteil des späteren Projekterfolges von der Schätzung für das Angebot ab. Gleiches gilt auch für Projekte, die nicht durch einen Dienstleister, sondern inhouse umgesetzt werden.

Doch wie kommt man zu einer guten Schätzung? Meiner Meinung nach gibt es hier keinen Königsweg. Schätzmethoden gibt es viele, doch nicht alle sind in jedem Umfeld sinnvoll. Über die Jahre habe ich für mich einige Best-Practices zusammengestellt. Diese möchte ich hier einmal zusammenfassen.

Agil oder klassisch schätzen?

Heute gibt es viele Schätzverfahren und Werte. Im agilen Umfeld wird oft mit Story Points gearbeitet. Manchmal mit mehr und manchmal mit weniger Erfolg. Warum Story Points so schwierig zu schätzen sind werde ich in einem anderen Artikel behandeln. Dies würde den Fokus in diesem Artikel zu sehr verschieben. Meine Erfahrung zeigt, dass Schätzungen in Projekten schlussendlich immer wieder auf harte Währung z.B. €s herunter gebrochen werden. (So hart oder weich die Währung halt ist ;-))

Einführung in die „klassische Schätzung“ um einen Aufwand zu ermitteln

Nun aber zu den Methoden des Schätzens. Es gibt unterschiedliche Schätzmethoden, mit denen der Aufwand für Entwicklungsprojekte erfasst werden kann. Diese sind z.B. agile Schätzmethoden wie Planing Poker mit Story Points, Drei- und Zweipunktschätzungen oder die Delphi-Methode (unabhängige Schätzung mehrerer Experten) und viele Weitere. Eine Übersicht dazu findet ihr auf Wikipedia unter Aufwandsschätzung und unter Schätzmethode.

Welche der Methoden genutzt werden bleibt den Schätzenden selbst überlassen. Dies ist abhängig von der Erfahrung, der Zeit und der Anzahl an verfügbaren Personen. Für mich haben sich Schätzungen nach der Delphi-Methode oder basierend auf vergleichbaren Projekten und Erfahrungen bewehrt. Wenn die Zeit und die Mitarbeiter verfügbar sind ist das Planing Poker, das ggf. statt Story Points auch Tage schätzen kann. Ein aufwendigeres aber durchaus sehr solides Vorgehen, um auf recht belastbare Zahlen zu kommen.

Bei allen Vorgehen gilt, dass ein paar grundlegende Regeln eingehalten werden sollten. Ein zukünftiger Projektleiter sollte die Möglichkeit haben die Schätzungen nachzuvollziehen und darauf basierend das Projekt tatsächlich planen zu können. Dazu sollte völlige Transparenz herrschen, was in der Schätzung enthalten ist und was nicht. Unsicherheiten und Risiken müssen dargelegt werden. Darüber hinaus sollte eine Schätzung einen finalen Preis für ein Angebot liefern können und auch dem Kunden möglichst transparent darstellen, welche Leistung/Werksstücke er für den aufgerufenen Preis erhält und welche nicht. Ist dies nicht der Fall, so habe ich schon sehr häufig erlebt, dass der Kunde Leistungen im Projektgeschäft erwartet, die vom ursprünglichen Schätzteam nicht berücksichtigt wurden. Und dann kommt es zu unnötigen Streitsituationen. Wer trägt für den zusätzlichen Aufwand die Kosten?

Politik – nicht schon bei der Schätzung

In und vor Projekten gibt es immer wieder persönliche und politische Aspekte, die den Projekterfolg beeinflussen. Seien es Streitigkeiten zwischen dem Kunden und Dienstleistern aus vorigen Projekten, vertragliche Unstimmigkeiten oder andere negativen „Einflüsse“. Politische und verkäuferische Aspekte in einem hart umkämpften Projekt haben in einer Schätzung nichts verloren. Hiervon sollte man bei einer Schätzung zunächst vollständig Abstand nehmen. Diese sind als separat als Risiko zu erkennen und festzuhalten. In der technischen Umsetzung haben sie nichts verloren. Diese Aspekte sind in einem nachgelagerten Teil einer verkäuferischen Entscheidung durch das Sales-Team und die Geschäftsführung zu bewerten und ggf. mit einzukalkulieren.

Niemals ohne ein Konzept schätzen

Wenn ich eine Schätzung erstelle, dann entsteht diese nicht auf der grünen Wiese. Als Basis dienen immer ein Grobkonzept der Architektur und der Implementierungsansatz. Erst, wenn ich weiß, wie ich ein Problem im Ansatz lösen möchte, kann ich einen Aufwand dafür beziffern. Daher gehören zu den wichtigsten Punkten vor eine Schätzung: Das verstehen der vollständigen Anforderungen des Kunden und eine Grobarchitektur für die Umsetzung. Dies muss kein vollständiges Pflichtenheft sein. Eine Aufteilung von Modulen, evtl. Komponenten und Schnittstellen ist hier sinnvoll. Je nach Projektumfang sind hier 1-5 Seiten mit 2-3 Grafiken völlig ausreichend.

Tabellarische Erfassung der Schätzung

Wenn ich eine Schätzung erstelle, dann verwende ich häufig eine Excel-Tabelle mit mindestens den folgenden Feldern:

Arbeitspaket: Bezeichnung des Arbeitspaketes, Moduls. z.B. Projektleitung, Implementierung, Testmanagement, Dokumentation, etc.
Aufgabe: Dies kann ein Titel der Tätigkeit, User Story oder das Modul sein. z.B. Testmanagement nach Abschluss der Implementierung/ Implementierung Dashboard für Startseite
Beschreibung: Eine stichpunktartige Beschreibung, was unter der Aufgabe verstanden wird. z.B. Aufsetzen des Testplans, Koordination Testing mit 5 Testern für 2 Wochen auf der Abnahmeumgebung/ Implementierung Dashboard mit ausschließlich lesendem Zugriff, 2 Graphen und einer Statusanzeige
Abgrenzung: Eine stichpunktartige Beschreibung, was NICHT in der Schätzung enthalten ist. z.B. Durchführen der Tests und Testing auf der Produktivumgebung, Entwicklertests / Bearbeitungsfunktion des Dashboards. Das Dashboard hat einen festen Bericht.
Risiken: Eventuell jetzt schon bekannte Risiken benennen. Z.B.: Anforderungen sind unklar beschrieben. Klärungsbedarf mit Kunden notwendig. Hier kann mehr Aufwand entstehen.
Min. Schätzung: Mindestdauer, um die Aufgabe vollständig umzusetzen. Hierzu gehören alle im folgenden Abschnitt detailliert aufgelisteten Tätigkeiten, wie z.B. Dokumentation, Testing, Installation…
Max. Schätzung: Unter der Annahme, dass ggf. die bekannten Risiken eintreten oder Implementierungsannahmen falsch waren der maximal zu erwartende Implementierungsaufwand.
Mittelwert: Mittelwert aus max. und min. Schätzung.

Was ist in der Schätzung enthalten und wer schätzt die Zahlen?

Unterschiedliche Aspekte des Projektes müssen auch durch unterschiedliche Rollen geschätzt werden. Aufwand, um die Architektur zu erstellen sollte sinnvollerweise gemeinsam mit einem Software-Architekten festgelegt werden. Die Implementierung mit den Entwicklern. Der Aufbau der Infrastruktur mit den Infrastruktur-Kollegen. Das Testen mit Testern. Und die Projektleitungs- oder Scrum Aufwendungen mit dem Projekleiter oder Scrum Master. Hierbei werden die tatsächlichen Aufwendungen erfasst mit allem, was getan werden muss.

Die wichtigsten Tätigkeiten sind:

technische Dokumentation,
erstellen der Testfälle,
Implementierung,
mit ggf. Unit Tests,
durchführen der Testfälle und
Installation des Features auf einem Kundensystem, um UATs durchzuführen
etc.

Bei der Schätzung von Querschnittsaufgaben ist vor allem die Projektdauer entscheidend. Diese Querschnittsaufgaben sind z.B. Projektleitung, Scrum Aufwendungen, User Acceptance Testing, Schulungen und Anwenderdokumentation. All diese müssen z.T. über die gesamte Projektlaufzeit berücksichtigt werden oder hängen von deren vereinbarten Umfang ab, z.B. Anzahl der zu schulenden Anwender. Diese Aufwendungen müssen mit dem zukünftigen Projektleiter im Einklang mit dem groben Projektplan geschätzt werden.

Wie wirken sich Risiken auf die Schätzung aus?

Jedes Projekt beinhaltet Risiken. Diese können teilweise schon in der Angebotsphase erkannt werden. Deshalb sollten diese Risiken bei der Schätzung mit benannt werden. Die Risiken sind meist technischer Natur und in der Schätzung mit aufzulisten. Wenn möglich sollte ein Vorschlag für die Reduktion des Risikos gemacht werden. Dies können beispielsweise folgende Vorgehensweisen sein:

Abgrenzung im Angebot/Task, dass dieser Punkt nicht Bestandteil des Angebots ist und separat zu betrachten/zuzuliefern ist
Risikoaufschlag auf das Gesamtprojekt/Teilprojekt
Risiko im Angebot benennen und dem Kunden/Projektleiter bekannt machen und darauf hinweisen

Abhängig von den Risiken kann dann auf das Projekt ein zusätzlicher Puffer aufgeschlagen werden, oder aber auch mit dem Kunden ein Vorgehen abgesprochen werden. Die Festlegung des Aufschlags sollte aber nicht vom Schätzteam selbst vorgenommen werden. Dies sind Unternehmerische Entscheidungen und obliegen der Geschäftsführung und des Sales Teams.

Schätzungen in a Nutshell

Die folgende Liste stellt kurz und knapp meine wichtigsten Punkte zusammen.

Klassische Schätzungen für Entwicklungsprojekte werden IMMER im strukturiert erfasst, nur so lassen sie sich auswerten und ggf anpassen, korrigieren
Einer Schätzung geht IMMER ein dokumentiertes Grobkonzept auf Basis der vorliegenden Kundenanforderungen voran
Eine Aufgabe erhält IMMER eine kurze Beschreibung, was zu der Aufgabe gehört – auch technisch
Eine Aufgabe erhält, wo möglich und sinnvoll, eine kurze Abgrenzung, was NICHT zu der Aufgabe gehört – auch technisch
Eine Implementierungsaufgabe enthält immer folgende Aufwendungen eines Entwicklers
- technische Dokumentation,
- erstellen der Testfälle,
- Implementierung
- mit ggf. Unit Tests,
- durchführen der Testfälle und
- Installation des Features auf einem Kundensystem, um UATs durchzuführen
- etc.
Eine Schätzung enthält keine Kundenrabatte, willkürliche Puffer, politische Preise oder ähnliches.
Querschnittsfunktionen (Projektleitung, Scrum Aufwendungen, Testmanagement, Schulungen etc.) werden mit Rücksprache des zukünftigen Projektleiters und der jeweils leistenden Personen ermittelt
Bekannte, technische Risiken werden erfasst und an den Angebotsverantwortlichen/Sales/die Geschäftsleitung weiter gegeben

Ich hoffe diese Zusammenfassung ist dem ein oder anderen Hilfreich und trägt ein klein wenig dazu bei, dass evtl. das ein oder andere IT-Projekt nicht schon VOR Projektbeginn zum Scheitern verurteilt ist.

Häppy schätzing 😉 !