Projektkostenschätzung: Techniken und Beispiele

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Die Projektkostenschätzung ist der Prozess, bei dem prognostiziert wird, wie viel Geld ein Projekt zur Erfüllung seines definierten Umfangs benötigt. Gelingt sie, schützen Sie Ihre Margen, gewinnen das Vertrauen der Stakeholder und halten Ihr Team fokussiert. Misslingt sie, drohen unangenehme Neuverhandlungen, Umfangskürzungen oder gleich die Absage des Projekts.
Dieser Leitfaden behandelt die fünf wichtigsten Schätztechniken, die Kostenarten, die Sie berücksichtigen müssen, typische Genauigkeitsbereiche und ein durchgerechnetes Beispiel, das Sie für Ihr nächstes Projekt anpassen können.
Was ist Projektkostenschätzung?
Projektkostenschätzung ist die Praxis, die finanziellen Ressourcen vorherzusagen, die zur Durchführung eines Projekts von der Initiierung bis zum Abschluss benötigt werden, basierend auf verfügbaren Umfangsinformationen, historischen Daten und Fachwissen. Sie ist eines der Kernergebnisse der Kostenmanagementplanung und fließt direkt in die Budget-Baseline des Projekts ein.
Schätzungen sind keine Vermutungen. Eine strukturierte Schätzung trägt einen angegebenen Genauigkeitsbereich und dokumentiert die Annahmen hinter jeder Zahl. Während das Projekt vom Konzept zum Detaildesign fortschreitet, werden Schätzungen fortschreitend präzisiert: Frühe grobe Zahlen weichen engeren, besser abgesicherten Zahlen.
Wichtige Fakten
- Laut einer Analyse großer Infrastrukturprogramme des McKinsey Global Institute überschreiten rund 85 % großer staatlicher IT-Projekte ihre ursprüngliche Kostenschätzung.
- Der Bericht "Pulse of the Profession" des Project Management Institute ergab, dass Organisationen im Schnitt 97 Millionen US-Dollar pro investierter Milliarde verschwenden, größtenteils aufgrund schlechter Umfangsdefinition und Unterschätzung.
- Die Forschung des Oxford-Professors Bent Flyvbjerg über 16.000 Projekte hinweg ergab, dass Kostenüberschreitungen bei 9 von 10 Projekten auftreten, mit einer durchschnittlichen Überschreitung von 30 %.
Techniken der Projektkostenschätzung
Fünf Techniken decken die große Mehrheit der Praxisfälle ab. Welche die richtige ist, hängt davon ab, wie viel Umfangsdetail Sie haben und wie viel Zeit Sie in die Schätzung investieren können.
| Technik | Wie sie funktioniert | Typische Genauigkeit | Wann anwenden |
|---|---|---|---|
| Analog | Nutzt tatsächliche Kosten eines ähnlichen vergangenen Projekts, angepasst an Größe oder Komplexität | -25 % bis +75 % (grobe Schätzung) | Frühe Machbarkeitsprüfung; begrenztes Umfangsdetail |
| Parametrisch | Multipliziert einen Einheitspreis mit einer messbaren Menge (z. B. Kosten pro Story Point, pro Quadratmeter) | -10 % bis +25 % | Wenn verlässliche Einheitskostendaten und ein messbarer Treiber vorliegen |
| Bottom-up | Schätzt jedes Arbeitspaket im Projektstrukturplan einzeln und summiert dann | -5 % bis +10 % | Detaillierte Planungsphase; höchster Aufwand und höchste Genauigkeit |
| Drei-Punkt-Schätzung | Mittelt optimistisches (O), wahrscheinlichstes (M) und pessimistisches (P) Szenario mittels PERT: (O + 4M + P) / 6 | Abhängig von den Eingaben; reduziert Verzerrung durch Einzelwerte | Unsichere oder neuartige Arbeit; kombiniert sich gut mit der Monte-Carlo-Simulation |
| Expertenurteil | Fachexperten liefern Schätzungen basierend auf Erfahrung | Breite Spanne | Neue Technologie oder Domäne; dient zum Gegenprüfen anderer Methoden |
Die Techniken schließen sich nicht gegenseitig aus. Die meisten erfahrenen Projektmanager kombinieren zwei oder mehr: eine analoge Schätzung für einen schnellen Plausibilitätscheck in der Angebotsphase, dann eine Verfeinerung per Bottom-up-Methode, sobald der PSP vollständig ist.
Für eine tiefere Erklärung der PERT-Formel und wann sie einfache Mittelwertbildung übertrifft, siehe Drei-Punkt-Schätzung.
Arten von Projektkosten
Bevor Sie präzise schätzen können, brauchen Sie ein gemeinsames Vokabular für die Kostenkategorien, mit denen Sie arbeiten.
Direkte Kosten sind Ausgaben, die spezifisch an das Projekt gebunden sind: Arbeitsstunden namentlich genannter Teammitglieder, gekaufte Materialien, Softwarelizenzen, Vertragspartnerhonorare und Reisen, die direkt mit Liefergegenständen zusammenhängen.
Indirekte Kosten (Gemeinkosten) werden über mehrere Projekte oder die gesamte Organisation geteilt: Büromiete, Nebenkosten, HR-Funktionen und der Anteil der IT-Infrastruktur, der dem Projekt zugeordnet wird.
Fixkosten ändern sich nicht mit Projektumfang oder -dauer: eine Softwarelizenzgebühr, ein Serverkauf oder eine einmalige Einrichtungsgebühr.
Variable Kosten skalieren mit der Aktivität: Tagessätze von Beratern, nach Stunden abgerechnete Cloud-Rechenleistung oder Druckkosten pro Dokument.
Risikorücklagen (Contingency Reserves) decken identifizierte Risiken ab, die eintreten können oder auch nicht. Sie liegen innerhalb der Kosten-Baseline und werden freigegeben, wenn ein Risikoereignis eintritt. Eine typische Rücklage liegt bei 5 % bis 15 % der Basisschätzung, abhängig vom Risikoexposure, das im Projektrisikomanagement identifiziert wurde.
Managementrücklagen decken unbekannte Unbekannte ab. Sie liegen außerhalb der Kosten-Baseline, erfordern eine formelle Freigabe für den Zugriff und sind nicht Teil der Earned-Value-Baseline. Wie Rücklagen mit der Kostenleistungsmessung zusammenwirken, erfahren Sie unter Earned Value Management (EVM).
Häufige Fehler bei der Projektkostenschätzung
Selbst erfahrene Projektmanager tappen in vorhersehbare Fallen.
Sich an der ersten Zahl festmachen (Anchoring). Sobald ein Sponsor eine grobe Zahl hört, wird sie zum Ziel. Schützen Sie frühe Schätzungen durch explizite Genauigkeitsangaben (siehe Genauigkeitsbereiche unten), damit Stakeholder die Spanne verstehen, nicht nur den Mittelwert.
Indirekte Kosten weglassen. Teams schätzen oft nur direkte Arbeit und Materialien und werden dann zum Abrechnungszeitpunkt von Gemeinkostenzuweisungen überrascht.
Integration und Testing vergessen. Diese Phasen verbrauchen routinemäßig 25 % bis 40 % des Gesamtaufwands, werden aber aus frühen Schätzungen herausgedrängt, weil sie in der Planung noch abstrakt wirken.
Einzelwert-Optimismus. Nur das "wahrscheinlichste" Szenario zu schätzen, ignoriert die Asymmetrie der Projektunsicherheit: Verzögerungen und Umfangserweiterungen sind häufig; vorzeitige Lieferung und Umfangskürzungen sind selten. Die Drei-Punkt-Schätzung und die Monte-Carlo-Simulation adressieren das direkt.
Die Dreifachbeschränkung ignorieren. Kosten, Umfang und Zeitplan hängen zusammen. Eine Schätzung ohne klare Umfangs-Baseline driftet ab, sobald Umfangsgespräche wieder aufgenommen werden.
Kein Änderungspuffer. Anforderungen ändern sich. Reservieren Sie eine formelle Risikorücklage, statt Änderungen still aufzufangen, was die wahren Kosten verschleiert und das Reporting verzerrt.
Wie man Projektkosten schätzt
Schritt 1: Die Umfangs-Baseline bestätigen
Man kann nicht schätzen, was man nicht definiert hat. Beginnen Sie mit dem Projektauftrag und der Umfangserklärung, erstellen oder prüfen Sie dann den Projektstrukturplan. Jedes Arbeitspaket braucht eine klare Beschreibung davon, wie "fertig" aussieht, bevor Sie einen Geldbetrag darauf ansetzen.
Schritt 2: Alle Kostenkategorien identifizieren
Listen Sie jede Kostenart auf, die im Projekt anfällt: interne Arbeitskraft (nach Rolle und Satz), externe Vertragspartner, Software und Hardware, Räumlichkeiten, Reisen, Schulungen und Gemeinkostenzuweisungen. Eine Kategorie an dieser Stelle zu übersehen, ist schwerer wieder aufzuholen als eine ungenaue Schätzung innerhalb einer Kategorie.
Schritt 3: Ihre Schätztechnik wählen
Passen Sie die Technik an die vorhandenen Informationen an. In der Konzeptphase sind analoge oder parametrische Schätzungen angemessen. Sobald der PSP vollständig ist, ist Bottom-up der Standard. Für Arbeitspakete mit hoher Unsicherheit wenden Sie die Drei-Punkt-Schätzung an.
Schritt 4: Jedes Arbeitspaket schätzen
Bei der Bottom-up-Schätzung weisen Sie jedem PSP-Arbeitspaket Kosten zu. Berücksichtigen Sie Arbeitskosten (Stunden multipliziert mit dem Mischsatz), Materialien und alle direkten Ausgaben. Dokumentieren Sie für jede Schätzung die Annahmen: "geht von einem Senior-Entwickler zu 150 $/Stunde für 40 Stunden aus" ist nachvollziehbar; "Entwicklung: 6.000 $" ist es nicht.
Schritt 5: Risikorücklagen hinzufügen
Prüfen Sie identifizierte Risiken aus dem Risikoregister (siehe Projektrisikomanagement). Schätzen Sie für jedes signifikante Risiko die Kostenauswirkung und Wahrscheinlichkeit. Summieren Sie die Erwartungswerte und fügen Sie sie als Zeile für die Risikorücklage hinzu. Fügen Sie die Managementrücklage als separate Zeile außerhalb der Baseline hinzu.
Schritt 6: Zusammenfassen und validieren
Summieren Sie die Arbeitspaketschätzungen plus Rücklage zur Kosten-Baseline. Prüfen Sie dann gegen mit einer Top-down-Technik: Wirkt Ihre Bottom-up-Gesamtsumme proportional zu ähnlichen vergangenen Projekten? Weichen die Zahlen deutlich ab, untersuchen Sie das, bevor Sie präsentieren.
Schritt 7: Annahmen dokumentieren und Freigabe einholen
Eine Schätzung ohne dokumentierte Annahmen ist nur eine Zahl. Halten Sie fest, was enthalten war, was ausgeschlossen war, welche Sätze verwendet wurden und welcher Genauigkeitsbereich gilt. Präsentieren Sie den Stakeholdern zur formellen Genehmigung, damit die Baseline zu einer gemeinsamen Verpflichtung wird, nicht zu einem Wunsch.
Schritt 8: Mit Earned Value überwachen
Sobald das Projekt beginnt, verfolgen Sie die tatsächlichen Ausgaben gegen die Baseline mit Earned Value Management (EVM). Fällt der Kostenleistungsindex (CPI) früh unter 0,9, schätzen Sie die Fertigstellung neu, statt auf eine Erholung zu hoffen, die selten eintritt. Verschiebt sich gleichzeitig der Zeitplan, ziehen Sie Fast Tracking vs. Crashing in Betracht und modellieren Sie die Kostenauswirkung jedes Ansatzes, bevor Sie sich festlegen.
Beispiel für eine Projektkostenschätzung
Ein Softwareteam baut ein Kundenportal. Hier eine vereinfachte Bottom-up-Schätzung für die erste Release-Phase.
| Arbeitspaket | Aufwand (Stunden) | Satz ($/Std.) | Arbeitskosten | Material / Sonstiges | Gesamt |
|---|---|---|---|---|---|
| Anforderungen und Design | 80 | 120 \(| 9.600\) | 0 \(| 9.600\) | ||
| Backend-API-Entwicklung | 200 | 150 \(| 30.000\) | 500 \((Cloud-Sandbox) | 30.500\) | ||
| Frontend-Entwicklung | 160 | 130 \(| 20.800\) | 200 \((UI-Kit-Lizenz) | 21.000\) | ||
| QA und Testing | 120 | 110 \(| 13.200\) | 300 \((Test-Tooling) | 13.500\) | ||
| Deployment und DevOps | 40 | 140 \(| 5.600\) | 800 \((Hosting erstes Jahr) | 6.400\) | ||
| Projektmanagement | 60 | 120 \(| 7.200\) | 0 \(| 7.200\) | ||
| Zwischensumme (Basisschätzung) | 660 | 86.400 $ | 1.800 $ | 88.200 $ | |
| Risikorücklage (10 %) | 8.820 $ | ||||
| Managementrücklage (5 %) | 4.410 $ | ||||
| Gesamtes Projektbudget | 101.430 $ |
Wichtige Annahmen: Senior-Entwicklersätze; 40-Stunden-Arbeitswochen; keine Infrastrukturmigration erforderlich; Umfang nach Sprint 0 eingefroren. Genauigkeitsbereich: minus 10 % bis plus 15 % (definitive Schätzung basierend auf abgeschlossenem PSP).
Ändern sich Umfang oder Zeitplan, gehen Sie zurück zu Schritt 1 und schätzen die betroffenen Arbeitspakete neu, statt die Gesamtsumme nach Gefühl anzupassen.
Best Practices für die Projektkostenschätzung
Historische Daten systematisch nutzen. Bauen Sie eine interne Satzkarte auf und pflegen Sie ein Lessons-Learned-Repository, das tatsächliche gegenüber geschätzten Kosten nach Projekttyp erfasst. Jedes abgeschlossene Projekt macht die nächste Schätzung genauer.
Schätzung von Verhandlung trennen. Die Schätzung sollte die Realität widerspiegeln. Ist das von der Führung genehmigte Budget niedriger, ist das ein Verhandlungsergebnis, kein Grund, die Schätzung zu beschneiden. Dokumentieren Sie die Lücke und die Risiken, die sie mit sich bringt.
Genauigkeitsbereiche explizit kennzeichnen. Eine grobe Schätzung (Rough Order of Magnitude, ROM) trägt eine Spanne von -25 % bis +75 %. Eine Budgetschätzung liegt bei -10 % bis +25 %. Eine definitive Schätzung liegt bei -5 % bis +10 %. Nutzen Sie diese Kennzeichnungen, damit Stakeholder ihre Erwartungen richtig kalibrieren.
Die Schätzung an Phasenübergängen überprüfen. Mit zunehmendem Umfangsdetail neu schätzen. Lassen Sie eine frühe ROM-Zahl nicht ohne formelles Re-Baselining zu einer verbindlichen Zusage erstarren.
Das gesamte Team einbeziehen. Die Menschen, die die Arbeit ausführen, haben das beste Gespür für Komplexität und Risiko. Sitzungen im Planning-Poker-Stil (siehe den agilen Ansatz unter Planning Poker, falls Ihr Team iterativ arbeitet) bringen Meinungsverschiedenheiten früh ans Licht, bevor sie zu Kostenüberraschungen werden.
Kostenleistung wöchentlich verfolgen. Ein CPI unter 1,0 bedeutet, dass Sie mehr ausgeben, als die Arbeit wert ist. Das in Woche 2 zu bemerken, lässt Spielraum zum Handeln; es in Woche 12 zu bemerken, bedeutet meist Schadensbegrenzung.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einer Kostenschätzung und einem Projektbudget? Eine Kostenschätzung ist die berechnete Vorhersage der Projektkosten. Ein Budget ist die genehmigte Version dieser Schätzung, mit autorisierten Finanzierungsniveaus, Rücklage und Managementrücklage. Die Schätzung fließt ins Budget ein; das Budget wird zur Steuerungs-Baseline.
Welche Technik der Projektkostenschätzung ist am genauesten? Die Bottom-up-Schätzung ist im Allgemeinen am genauesten, weil sie aus detaillierten Arbeitspaketdaten aufgebaut wird. Sie erfordert aber einen vollständigen PSP und nimmt erheblich Zeit in Anspruch. Die parametrische Schätzung kann die Bottom-up-Genauigkeit erreichen, wenn verlässliche Einheitskostendaten vorliegen. Für neue oder stark unsichere Arbeit liefert die Drei-Punkt-Schätzung kombiniert mit der Monte-Carlo-Simulation eine Wahrscheinlichkeitsverteilung statt einer Einzelzahl, was ehrlicher mit Unsicherheit umgeht.
Wie hoch sollte die Risikorücklage eines Projekts sein? Es gibt keine universelle Antwort. Eine typische Spanne liegt bei 5 % bis 20 % der Basisschätzung. Die richtige Zahl ergibt sich aus Ihrem Risikoregister: identifizieren Sie Risiken mit hoher Auswirkung, schätzen Sie deren erwarteten Kostenwert und nutzen Sie das als Untergrenze. Projekte mit neuartiger Technologie, regulatorischer Unsicherheit oder Festpreisverträgen an einem der beiden Enden der Lieferkette sollten höhere Rücklagen tragen.
Was ist eine ROM-Schätzung? ROM steht für Rough Order of Magnitude (grobe Größenordnung). Sie wird in den frühesten Projektphasen verwendet, wenn der Umfang noch unscharf ist. Der typische Genauigkeitsbereich liegt bei -25 % bis +75 %. Sie ist für Machbarkeitsentscheidungen geeignet, sollte aber niemals als Budgetzusage verwendet werden.
Kann man Kosten in Agile-Projekten schätzen? Ja. Agile Teams nutzen typischerweise parametrische Schätzung (Kosten pro Story Point, basierend auf historischer Velocity) kombiniert mit rollierender Planung. Sie schätzen den nächsten Sprint im Detail und nutzen relative Größeneinschätzung für zukünftige Sprints. Kostenschätzungen auf Release-Ebene nutzen historischen Durchsatz, um die Gesamtzahl der Story Points zu projizieren, und multiplizieren dann mit den Kosten pro Punkt. Der Ansatz orientiert sich daran, wie Velocity in Agile verfolgt wird.
Zusammenfassung
Projektkostenschätzung ist teils Wissenschaft, teils Urteilsvermögen. Die Wissenschaft besteht darin, die richtige Technik für Ihren aktuellen Detailgrad des Umfangs zu wählen, alle Kostenarten zu berücksichtigen und eine vertretbare Rücklage aufzubauen. Das Urteilsvermögen entsteht aus der Kenntnis des Tempos Ihres Teams, der Gemeinkostenstruktur Ihrer Organisation und der Stellen, an denen vergangene Schätzungen zu optimistisch waren.
Beginnen Sie mit einer klaren Umfangs-Baseline, dokumentieren Sie jede Annahme, kennzeichnen Sie Ihren Genauigkeitsbereich ehrlich und überprüfen Sie die Schätzung an jedem Phasenübergang. Diese konsequent angewendete Disziplin unterscheidet Teams, die im Budget liefern, von solchen, die die halbe Projektzeit damit verbringen, Überschreitungen zu erklären.
Weiterführende Artikel

Senior Operations & Growth Strategist
On this page
- Was ist Projektkostenschätzung?
- Techniken der Projektkostenschätzung
- Arten von Projektkosten
- Häufige Fehler bei der Projektkostenschätzung
- Wie man Projektkosten schätzt
- Schritt 1: Die Umfangs-Baseline bestätigen
- Schritt 2: Alle Kostenkategorien identifizieren
- Schritt 3: Ihre Schätztechnik wählen
- Schritt 4: Jedes Arbeitspaket schätzen
- Schritt 5: Risikorücklagen hinzufügen
- Schritt 6: Zusammenfassen und validieren
- Schritt 7: Annahmen dokumentieren und Freigabe einholen
- Schritt 8: Mit Earned Value überwachen
- Beispiel für eine Projektkostenschätzung
- Best Practices für die Projektkostenschätzung
- Häufig gestellte Fragen
- Zusammenfassung
- Weiterführende Artikel