Das Versprechen ist klar: Sie füttern eine KI mit Projektbeschreibung, Mitarbeiterdaten und Lieferantenkatalog, und sie erstellt eine detaillierte Kostenkalkulation, in Minuten statt in Wochen. Keine Tabellenarchäologie mehr. Kein Nachhaken mehr beim Einkauf, um an Lieferantenangebote zu kommen. Theoretisch.
Mehrere Forschungsteams und Startups arbeiten bereits an dieser Zukunft. Die ersten Ergebnisse deuten auf echten Fortschritt hin, aber auch auf neue Wege, wie Schätzungen katastrophal danebengehen können.
Das alte Problem, das nicht verschwindet
IT-Projekte sind bei der Kostenschätzung notorisch schlecht. Eine Untersuchung von McKinsey und der Universität Oxford über mehr als 5.400 IT-Projekte kam zu dem Ergebnis, dass traditionelle Methoden im Schnitt zu Budgetüberschreitungen von 45 % führen. Traditionelle Ansätze erreichen eine Genauigkeit, die zwischen 30 % und 50 % schwankt, typischerweise bei einem Projektfortschritt von 1 % bis 15 %.
Genaue Kostenkalkulationen zu erstellen bleibt mühsam: Abstimmung mit technischen Architekten, HR, Einkauf und Finanzabteilung. Jede Runde wirft neue Fragen auf, zu Staging-Umgebungen, Disaster-Recovery-Plänen und zum Volumen der API-Aufrufe. Projektleiter berichten, dass sie viel Zeit in Schätzungen stecken, die bei der Umsetzung besser aufgehoben wäre.
Am Ablauf hat sich seit Jahrzehnten im Grunde nichts geändert: immer noch Tabellenkalkulationen, fundierte Vermutungen und hoffnungsvolle Annahmen.
Was die Forschung zeigt
Nehmen wir ein typisches Projekt: der Bau eines internen CRM-Systems mit Benutzerauthentifizierung, Reporting-Dashboards und mobilem Zugriff. Ein menschlicher Schätzer wäre tagelang damit beschäftigt, das aufzuschlüsseln, mit Architekten über die Datenbankanforderungen zu sprechen, die Preise der Anbieter für Cloud-Hosting zu prüfen und ähnliche frühere Projekte zum Vergleich heranzuziehen.
Eine im September 2024 auf arXiv veröffentlichte Studie (sie wertet mehrere reale Datensätze aus) stellt einen Ansatz vor, der mit Large Language Models die Genauigkeit und Nutzbarkeit von Kostenprognosen verbessern soll. Die Forscher stellten die These auf, dass LLMs den Schätzprozess vereinfachen, bei den meisten Softwareprojekten funktionieren und genauer sein könnten als bisherige Ansätze. Im Mittelpunkt stand die Frage, ob LLMs bestehende Modelle übertreffen und sich in die gängige Praxis einfügen lassen.
Technisch geht das wirklich. Moderne LLMs sind sehr gut darin, unstrukturierten Text auszuwerten, Anforderungen abzuleiten und Informationen zu strukturieren. An Unternehmensdatenbanken angebunden (Stundensätze der Mitarbeiter, Lieferantenverträge, Daten früherer Projekte), können sie Kostenkalkulationen in Minuten entwerfen.
Ein im April 2025 veröffentlichter systematischer Review fasst die Ergebnisse von 39 Studien aus den Jahren 2016 bis 2024 zusammen und bewertet Machine-Learning-, Deep-Learning- und Hybridmodelle in Bauwesen, Gesundheitswesen, Fertigung und Immobilienwirtschaft. KI-gestützte Ansätze, vor allem künstliche neuronale Netze (26,33 % der Studien), verbesserten die Prognosegenauigkeit und die Anpassungsfähigkeit an komplexe Projektumgebungen.
Machine-Learning-Ansätze legten 2021 deutlich zu, was auf eine wachsende Verbreitung in der Kostenschätzung hindeutet. In den Jahren 2023 und 2024 ließ die Aktivität nach. Das spricht entweder für ein Plateau beim Forschungsinteresse oder für eine Verlagerung hin zur Verfeinerung der Modelle für den breiteren Einsatz.
Auch erste Werkzeuge für die Praxis tauchen auf. CostGPT, ein kommerzieller Dienst, nimmt für sich eine Genauigkeit von über 80 % in der Projektplanung in Anspruch (wobei die Methodik kein Peer Review durchlaufen hat). Wie verlässlich das ist, hängt stark davon ab, wie gut und detailliert die Eingaben sind.
Das 3-Millionen-Dollar-Problem
Hier trifft die Begeisterung auf die Wirklichkeit. Ein LLM kann „Baue ein Kundenportal mit Benutzerauthentifizierung“ lesen und daraus eine völlig vernünftige Schätzung machen. Aber was heißt „Benutzerauthentifizierung“ eigentlich?
Einfacher Benutzername und Passwort? Ein paar Tage Entwicklung. Single Sign-on mit Active Directory? Eine Woche mehr plus Kosten für Enterprise-Lizenzen. Multi-Faktor-Authentifizierung? SMS-Gateway-Gebühren und zusätzliche Entwicklungszeit. Biometrische Authentifizierung auf Mobilgeräten? Dann reden wir von nativer App-Entwicklung, Sicherheitsprüfungen und Compliance-Fragen.
Das sind keine Sonderfälle. Das ist die normale Komplexität der Unternehmens-IT, und sie steckt in den Köpfen der Leute, in E-Mail-Verläufen und in undokumentierten Architekturentscheidungen. Eine Projektbeschreibung allein erfasst diese Feinheiten selten.
„Man kann nicht automatisieren, was man nicht konsistent messen kann. Und die meisten IT-Organisationen können nicht konsistent messen.“
Wenn Datenqualität auf die Wirklichkeit trifft
LLMs sind nur so gut wie ihre Trainingsdaten. Sind die historischen Projektdaten unsauber (uneinheitliche Kategorien, schlecht dokumentierte Annahmen, lückenhafte Kostenverfolgung), lernt die KI aus diesen Problemen und schreibt sie fort. Eine „Mobile App“ kann in der einen Abteilung ein React-Native-Wrapper sein und in der anderen eine vollständige native Anwendung mit Offline-Synchronisierung. Die Kosten unterscheiden sich um eine Größenordnung, die Bezeichnung ist dieselbe.
Viele Unternehmen arbeiten mit veralteter ERP-, Buchhaltungs- und Projektmanagement-Software. KI-Werkzeuge müssen sich nahtlos in diese Altsysteme einfügen, aber oft sind sie damit nicht kompatibel. Als Lösungen kommen API-kompatible Werkzeuge, Cloud-Implementierungen für den Datenaustausch in Echtzeit und Sandbox-Tests vor dem Deployment infrage.
Das ist das klassische Problem im Machine Learning: Man kann nicht automatisieren, was man nicht konsistent messen kann. Unternehmen, die auf KI-gestützte Kostenschätzung hoffen, stellen fest, dass sie zuerst die uneinheitliche Projektdokumentation aus Jahrzehnten bereinigen müssen. Diese wenig glamouröse Voraussetzung hat niemand budgetiert.
Was heute tatsächlich funktioniert
Trotz dieser Schwierigkeiten entstehen praktische Anwendungen. Das Weltwirtschaftsforum schätzt, dass der Einsatz von KI die Kosten von Bauprojekten um 20 % und die Projektdauer um 15 % senken kann (die Zahlen stammen aus dem Bauwesen, aber die IT hat bei der Schätzung strukturell ähnliche Probleme). Diese Vorteile setzen allerdings eine saubere Umsetzung und gute Datenqualität voraus, und das sind Annahmen, die oft nicht zutreffen.
Die erfolgreichsten Umsetzungen setzen auf Unterstützung statt auf vollständige Automatisierung:
Entwürfe erstellen: LLMs erstellen erste Kostenkalkulationen, die die offensichtlichen Anforderungen erfassen und klärungsbedürftige Punkte markieren. Damit ist das Problem der leeren Tabelle gelöst.
Risikobewertung: KI-Systeme erkennen mögliche Risikofaktoren in historischen Daten. Hatten ähnliche Projekte in der Vergangenheit in bestimmten Jahreszeiten Materialkostenüberschreitungen von 30 %, passt das System die Risikoreserven automatisch an und schlägt Vorbeugemaßnahmen vor.
Mustererkennung: Die KI berücksichtigt die besonderen Anforderungen eines Projekts, auch die lokalen Arbeits- und Materialkosten, und passt die Schätzung an den jeweiligen Kontext an.
Anpassung in Echtzeit: Die Systeme aktualisieren die Kostenschätzung laufend, während das Projekt voranschreitet, und berücksichtigen veränderte Bedingungen wie Lieferkettenstörungen oder Arbeitskräftemangel. Steigen die Stahlpreise mitten im Projekt sprunghaft, kann das System die Prognose der Beschaffungskosten automatisch anpassen.
Ein realistischer Ansatz
Statt eine vollständige Automatisierung zu versuchen, würde eine praxistaugliche Umsetzung Folgendes tun:
- Erste Entwürfe erzeugen: Ein LLM erstellt aus der Projektbeschreibung eine vorläufige Kostenkalkulation und greift dabei auf Mitarbeiterdaten und Lieferantenkataloge zu
- Unsicherheiten markieren: Das System benennt ausdrücklich, wo ihm Informationen oder Sicherheit fehlen
- Vergleichbare Projekte heranziehen: Es schlägt ähnliche frühere Projekte vor, für den Realitätscheck und zum Lernen
- Gezielte Fragebögen erzeugen: Strukturierte Fragen sammeln die fehlenden wichtigen Informationen ein
- Mehrere Szenarien erstellen: Verschiedene Vorgehensweisen werden mit unterschiedlichen Annahmen durchgerechnet, um die Bandbreite der möglichen Kosten zu zeigen
Dieser Ansatz behandelt die Kostenschätzung als iterativen Dialog zwischen KI und menschlicher Expertise, nicht als Automatisierungsaufgabe, die sich in einem Durchgang erledigen lässt. Die KI übernimmt das mühsame Sammeln und Strukturieren der Daten. Die Menschen liefern Kontext, Urteilsvermögen und Fachwissen, und genau das unterscheidet gute Schätzungen von Katastrophen.
Die Anbindung der KI an Unternehmenssysteme wie ERP und Projektmanagement-Werkzeuge liefert einen umfassenden Blick auf das Projekt und verbessert die Genauigkeit weiter, wenn sie sauber umgesetzt ist.
Auf lange Sicht
Das eigentliche Potenzial liegt nicht darin, die Kostenschätzung heute zu automatisieren, sondern in Feedbackschleifen, die sie mit der Zeit verbessern. Wenn KI-Systeme verfolgen, wie Schätzungen und tatsächliche Kosten zueinander stehen, Muster bei Kostenüberschreitungen erkennen und lernen, welche Projektmerkmale mit Unterschätzung zusammenhängen, könnten sie traditionelle Schätzteams nach und nach übertreffen.
Das verlangt eine organisatorische Disziplin, die man in der Praxis selten sieht: detaillierte Projektdaten erfassen, Annahmen dokumentieren, Abweichungen nachverfolgen und all das wieder ins System zurückspielen. Schätzen wird damit zu einer Lernaufgabe und hört auf, eine einmalige Übung zu sein. Am besten aufgestellt sind Organisationen mit weit zurückreichenden Projektdaten (große Rüstungskonzerne, die NASA, große Finanzinstitute), denn sie verfügen über Jahrzehnte (hoffentlich) gut dokumentierter Projektergebnisse.
Einige Organisationen bauen diese Fähigkeit gerade auf. Die meisten überlegen noch, wie sie ihr HR-System mit ihren Projektmanagement-Werkzeugen verbinden.
Jenseits des Hypes
Die Technik für KI-gestützte Kostenschätzung funktioniert wirklich. LLMs können Projektbeschreibungen auswerten, Kostendaten strukturieren und Muster in historischen Projekten erkennen. Die Frage ist nicht, ob die Technik das kann. Das kann sie offensichtlich.
Die Frage ist, ob Organisationen die wenig glamouröse Arbeit auf sich nehmen, die die Technik erst nützlich macht: Daten bereinigen, Prozesse standardisieren, Feedbackschleifen aufbauen. Das entspricht dem allgemeinen Muster bei der Einführung von KI in Unternehmen: Die Technik ist selten der Engpass. Der Engpass ist die Bereitschaft der Organisation.
Vorerst besteht die realistischste Anwendung darin, Projektleitern bessere Werkzeuge für das zu geben, was sie ohnehin tun, nur schneller und mit weniger vergessenen Positionen. Revolutionär ist das nicht, aber für alle, die schon eine Woche lang Lieferantenangeboten nachgelaufen sind und Gemeinkostenzuschläge berechnet haben, ist es ein Fortschritt.
Und anders als KI-Anwendungen, die versprechen, Strategie oder Kreativität zu revolutionieren, hat die Automatisierung von Kostenkalkulationen einen klaren Erfolgsmaßstab: Hat die Schätzung mit der Wirklichkeit übereingestimmt? Diese harte Feedbackschleife könnte KI-Systeme tatsächlich dazu zwingen, in etwas gut zu werden, und das wäre erfrischend.
Hier ist ein umfassender Prompt, mit dem Sie eine Kostenkalkulation per LLM erstellen können:
# Project Cost Sheet Generation
You are an expert project cost estimator. Your task is to analyze a project description and generate a detailed, professional cost sheet by leveraging the provided company data.
## Available Data Sources
You have access to the following information:
1. **Employee Database** (employee_data.xlsx):
- Employee ID, Name, Role/Title, Department
- Hourly rate or annual salary
- Skills and certifications
- Availability percentage
- Experience level (Junior/Mid/Senior)
2. **Supplier Catalog** (supplier_catalog.xlsx):
- Supplier name and contact
- Product/service categories (software licenses, hardware, cloud services, consulting)
- Unit pricing and volume discounts
- Contract terms and minimum commitments
- Lead times
3. **Historical Projects Database** (historical_projects.xlsx):
- Project descriptions and types
- Actual hours by role and phase
- Technologies used
- Final costs vs. estimates
- Duration and team size
- Lessons learned and risk factors
4. **Company Standards** (company_standards.xlsx):
- Standard overhead percentage (e.g., 25% for facilities, admin, benefits)
- Contingency buffer guidelines by project type (e.g., 10-20%)
- Standard project phases and typical effort distribution
- Approved vendors and preferred pricing
## Project Description
[INSERT PROJECT DESCRIPTION HERE]
Example:
"We need to build an internal CRM system for our sales team of 50 users. The system should include:
- Customer contact management with custom fields
- Deal pipeline tracking with stages
- Email integration (Office 365)
- Basic reporting and dashboards
- Mobile access (iOS and Android)
- Single sign-on with Active Directory
- Integration with our existing ERP system (SAP)
Target launch: 6 months from kickoff
Expected usage: 50 concurrent users, 200 customers initially, growing to 2,000 over 2 years"
## Your Task
Generate a comprehensive cost sheet following these steps:
### 1. Requirement Analysis
Parse the project description and identify:
- **Core features and functionality** required
- **Technical requirements** (authentication, integrations, platforms)
- **Non-functional requirements** (scalability, performance, security)
- **Technology stack** needed (programming languages, frameworks, databases, cloud services)
- **Required skillsets** (developers, designers, QA, DevOps, project management)
- **Third-party services** (licenses, APIs, hosting)
- **Deployment requirements** (infrastructure, environments)
### 2. Team Composition
Based on requirements and employee database:
- **Map required skills** to available employees
- **Suggest team composition** with specific roles:
- Project Manager
- Technical Lead/Architect
- Backend Developers
- Frontend Developers
- Mobile Developers (if needed)
- UI/UX Designer
- QA Engineer
- DevOps Engineer
- **Specify allocation** (full-time, part-time, percentage)
- **List employee IDs and rates** for each role
### 3. Effort Estimation
Using historical projects as reference:
- **Break down work by phases**:
- Discovery & Planning
- Design & Architecture
- Development (by component/feature)
- Testing & QA
- Deployment & Launch
- Documentation & Training
- **Estimate hours per phase** for each role
- **Reference similar projects** from historical database
- **Adjust estimates** based on complexity factors:
- Integration complexity
- Custom vs. off-the-shelf components
- Team experience with technology stack
- Regulatory/compliance requirements
### 4. External Costs
From supplier catalog, identify and price:
- **Software licenses** (development tools, third-party libraries)
- **Cloud services** (hosting, storage, databases, compute)
- **Third-party APIs** (email services, payment gateways, etc.)
- **Hardware** (if needed for development/testing)
- **External consultants** (if specialized expertise needed)
- **Training** (for team or end users)
### 5. Cost Sheet Structure
Generate a detailed cost sheet with these sections:
**A. Labor Costs**
| Role | Employee ID | Name | Hours | Rate | Subtotal |
|---|---|---|---|---|---|
| [For each role and phase] |
Total Labor: $XXX,XXX
**B. External Services & Software**
| Category | Item | Supplier | Quantity/Period | Unit Cost | Subtotal |
|---|---|---|---|---|---|
| [Licenses, subscriptions, services] |
Total External: $XXX,XXX
**C. Infrastructure & Hardware**
| Item | Specs | Quantity | Unit Cost | Subtotal |
|---|---|---|---|---|
| [If applicable] |
Total Infrastructure: $XXX,XXX
**D. Cost Summary**
Direct Labor Cost: $XXX,XXX External Costs: $XXX,XXX Infrastructure: $XXX,XXX ———- Subtotal: $XXX,XXX
Overhead (XX%): $XXX,XXX ———- Subtotal with Overhead: $XXX,XXX
Contingency (XX%): $XXX,XXX ———- TOTAL ESTIMATED COST: $XXX,XXX
### 6. Assumptions & Risk Factors
Document key assumptions:
- **Team availability** and allocation percentages
- **Technology choices** and rationale
- **Integration complexity** assumptions
- **Scope boundaries** (what's included/excluded)
- **Dependencies** on external teams or systems
Flag uncertainties requiring clarification:
- Ambiguous requirements needing stakeholder input
- Missing information about existing systems
- Assumptions about user load or data volumes
- Decisions needed on build vs. buy
- Regulatory or compliance requirements unclear from description
### 7. Comparable Projects
Reference 2-3 similar historical projects:
Project: [Name/ID] Similarity: [Why it’s comparable] Actual Cost: $XXX,XXX Variance from estimate: +/- XX% Key lesson: [What we learned]
### 8. Alternative Scenarios
Provide 3 cost scenarios:
**Scenario 1: Minimal (Must-Have Features Only)**
- Core features only
- Reduced team or longer timeline
- Off-the-shelf solutions where possible
- Estimated cost: $XXX,XXX
**Scenario 2: Recommended (As Described)**
- Full requirements as stated
- Balanced team composition
- Mix of custom and purchased solutions
- Estimated cost: $XXX,XXX
**Scenario 3: Enhanced (Future-Proofed)**
- Additional scalability features
- Enhanced security/compliance
- Better documentation and testing
- Estimated cost: $XXX,XXX
## Output Format
Provide your response in the following structure:
1. **Executive Summary** (2-3 paragraphs)
- Project overview
- Recommended approach
- Total estimated cost and timeline
- Key assumptions
2. **Detailed Cost Breakdown** (as structured above)
3. **Team Composition Table**
4. **Timeline & Phases**
- Phase breakdown with durations
- Milestones and deliverables
5. **Assumptions & Clarifications Needed**
- List all assumptions made
- Questions requiring stakeholder input
6. **Risk Assessment**
- Technical risks
- Resource risks
- Schedule risks
- Mitigation strategies
7. **Comparable Projects**
8. **Alternative Scenarios**
## Important Guidelines
- **Be specific**: Use actual employee IDs, names, and rates from the database
- **Show your work**: Reference which historical projects informed your estimates
- **Flag uncertainties**: Explicitly state where you lack information
- **Use realistic numbers**: Don't just guess—base estimates on historical data
- **Consider all costs**: Include often-forgotten items like licenses, testing environments, training
- **Be conservative**: When uncertain, err on the side of higher estimates
- **Provide ranges**: For uncertain items, give a range (e.g., $50K-$75K)
- **Explain variances**: If similar projects had very different costs, explain why
## Constraints
- Only use employees from the provided database
- Only use suppliers from the approved catalog
- Follow company standard overhead and contingency percentages
- If required skills aren't available in-house, note external hiring needs
- If required vendors aren't in catalog, flag as "needs procurement approval"
Dieser Aufbau des Prompts stellt sicher, dass das LLM:
- alle nötigen Kontextinformationen und Datenquellen hat
- einem systematischen Analyseablauf folgt
- ein professionelles, detailliertes Ergebnis liefert
- Unsicherheiten markiert, statt unbegründete Annahmen zu treffen
- vergleichbare Referenzen und alternative Szenarien liefert
- alle Annahmen zur Prüfung dokumentiert
Die Abschnitte zu Datenquellenformaten und Unternehmensstandards können Sie an Ihre tatsächlichen Dateistrukturen und organisatorischen Anforderungen anpassen.
Aus dem Englischen übersetzt: zum Originalbeitrag