Softwareentwicklung nach Aufwand: Stunden kontrollieren

Wie Time & Materials tatsächlich funktioniert und wofür der Kunde bezahlt

Die Mechanik passt in einen Satz: Der Kunde bezahlt einen vereinbarten Stundensatz für die Zeit, die das Team tatsächlich in das Projekt investiert. Die Sätze unterscheiden sich in der Regel nach Rolle, sodass ein Senior-Backend-Entwickler, ein QA-Spezialist und ein Business Analyst unterschiedlich abgerechnet werden. Die Zeit wird auf konkrete Aufgaben gebucht und in einem vereinbarten Rhythmus berichtet. Es gibt keine im Voraus fixierte Gesamtsumme, weil die Summe davon abhängt, wie viel Arbeit das Projekt am Ende benötigt. Das ist die gesamte Arithmetik - der Rest dieses Abschnitts erklärt, warum es dieses Modell überhaupt gibt.

Time & Materials existiert, weil ernsthafte Softwarearbeit in den meisten Fällen einen beweglichen Scope hat. Ein SaaS-Produkt ändert die Richtung, sobald die erste Gruppe zahlender Nutzer da ist. Ein CRM-Rollout fördert drei Abteilungen zutage, deren Abläufe nie jemand dokumentiert hat. Ein Integrationsprojekt trifft auf eine Partner-API, die sich anders verhält als ihre Spezifikation. In allen drei Fällen wäre ein im ersten Monat eingefrorener Scope im dritten Monat falsch. Die Abrechnung nach Aufwand erlaubt es dem Plan, dem Geschäft zu folgen, statt das Geschäft zu zwingen, einem Plan zu folgen, der geschrieben wurde, bevor jemand die Fakten kannte.

Diese Flexibilität funktioniert nur, wenn jemand das Backlog verantwortet. Ein Backlog ist schlicht die geordnete Liste all dessen, was das Team bauen könnte, mit den wertvollsten Punkten oben. Bei Time & Materials behält der Kunde echte Kontrolle über diese Reihenfolge: was nach oben rückt, was nach unten wandert, was gestrichen wird. Priorisierung ist der wichtigste Kostenhebel des Kunden in diesem Modell - und sie wirkt weit stärker als jede Verhandlung über den Stundensatz.

Die beiden Modelle verorten das Risiko einer falschen Schätzung außerdem unterschiedlich. Beim Festpreis trägt es der Dienstleister, weshalb ein Festpreisangebot immer einen Risikopuffer enthält, den Sie weder sehen noch prüfen können. Bei Time & Materials trägt es der Kunde, weshalb das Risiko in der Stundenzahl sichtbar wird. Sichtbares Risiko fühlt sich unangenehm an, und genau dieses Unbehagen ist der Grund für diesen Artikel. Auf den vollständigen Vergleich kommen wir später zurück, denn die ehrliche Fassung ist interessanter als die übliche.

Nun zu dem Missverständnis, das man früh ausräumen sollte: Time & Materials bedeutet nicht unbegrenztes Budget. Professionell geführte Aufwandsprojekte arbeiten mit Kostenobergrenzen je Iteration oder Phase, mit vereinbarten Schwellenwerten, ab denen das Team anhalten und nachfragen muss, und mit einer rollierenden Prognose der Kosten für die kommende Periode. Diese Instrumente behandelt der Governance-Abschnitt weiter unten im Detail. Ein Projekt ohne sie ist kein Preismodell, sondern eine offene Rechnung.

Unter Entwicklungsdienstleistern ist das Modell weit verbreitet. ScienceSoft gibt auf seiner Preisseite an, dass mehr als 90 % der eigenen Entwicklungsprojekte nach Aufwand abgerechnet werden. Diese Zahl beschreibt das Portfolio eines einzelnen Anbieters, nicht den Softwaremarkt insgesamt, und sie sollte auch so gelesen werden. Sie zeigt, dass Dienstleister mit komplexen, langlaufenden Projekten in der Regel zur Abrechnung nach Aufwand tendieren - und sie sagt nichts darüber aus, welcher Anteil der weltweiten IT-Ausgaben über dieses Modell läuft. Das Muster wiederholt sich über Branchen hinweg: Ein recherchelastiges Vorhaben wie Immobilien Webseite erstellen wird aus genau demselben Grund nach Aufwand abgerechnet.

Warum eine einzelne Rechnung nicht verrät, ob eine Aufgabe 10, 20 oder 40 Stunden dauern darf

Angenommen, Sie erhalten eine Position mit dem Wortlaut "Kundenexport in die Buchhaltung - 26 Std.". Aus dieser Zeile allein können Sie die Zahl nicht beurteilen. Der Grund ist nicht, dass Dienstleister Informationen zurückhalten. Der Grund ist, dass die Kosten einer Softwareaufgabe von der Umgebung bestimmt werden, in der sie landet - und diese Umgebung ist von außerhalb der Codebasis unsichtbar. Dieselbe Funktion, mit denselben Worten beschrieben, kann in einem System ehrlich 6 Stunden und in einem anderen 40 Stunden kosten.

Dies sind die Variablen, die die Zahl legitim verschieben, und jede einzelne davon ist real:

• Zustand der bestehenden Codebasis. Sauberer, getesteter Code nimmt eine Änderung schnell auf. Code, der acht Jahre ohne Refactoring gewachsen ist, wehrt sich dagegen.
• Legacy-Komponenten. Ein altes Modul, das niemand im aktuellen Team geschrieben hat, muss erst verstanden werden, bevor man es gefahrlos anfassen kann.
• Qualität der Dokumentation. Wenn Verhalten nicht dokumentiert ist, muss jemand es durch Codelektüre und Experimente rekonstruieren.
• Integrationen. Jedes System auf der anderen Seite einer Schnittstelle hat sein eigenes Datenmodell, sein eigenes Fehlerverhalten und seine eigenen Ausfallmuster.
• Fremd-APIs. Rate Limits, Sandboxes, die sich von der Produktion unterscheiden, Authentifizierungsverfahren und undokumentierte Sonderfälle kosten allesamt reale Zeit.
• Debugging. Die Ursache eines Fehlers zu finden, ist Forschungsarbeit - und Forschung folgt keinem planbaren Zeitplan.
• Testing. Ein Zahlungsprozess braucht eine andere Prüftiefe als eine interne Verwaltungsmaske.
• Infrastrukturabhängigkeiten. Pipelines, Umgebungen, Zugriffsrechte und Datenmigrationen liegen zwischen fertigem Code und einer lauffähigen Funktion.
• Randbedingungen, die vor Arbeitsbeginn nicht bekannt sein konnten. Eine Sicherheitsanforderung oder ein Datenvolumen, das erst auftaucht, wenn jemand das System öffnet.
• Notwendige Recherche. Die Wahl zwischen zwei technischen Ansätzen kostet Zeit, selbst wenn das anschließende Programmieren schnell geht.

Der Schluss für die Auftraggeberseite folgt unmittelbar: Es gibt keine Branchentabelle mit Normstunden je Aufgabe, und jeder Anbieter, der Ihnen eine anbietet, verkauft Ihnen eine Fiktion. Die Vergleichseinheit ist nicht der Name der Funktion, sondern die Funktion in einem konkreten System, mit konkreten Daten und konkreten Randbedingungen. Ihre Rechnung daran zu messen, was ein Kollege für eine "ähnliche" Integration bezahlt hat, erzeugt Rauschen statt Erkenntnis.

Die Schwierigkeit ist nicht anekdotisch, sondern dokumentiert. Jørgensen und Shepperd haben in ihrer systematischen Übersicht zu Studien der Kostenschätzung in der Softwareentwicklung 304 Fachbeiträge aus 76 Journals katalogisiert. Die Aufwandsschätzung in der Softwareentwicklung ist ein eigenes Forschungsfeld mit jahrzehntelanger Literatur - und zwar genau deshalb, weil es keine einfache Stundennorm gibt.

Eine Schätzung ist eine Prognose, keine garantierte Stundenzahl

Das ist die wirkungsvollste Korrektur, die ein Auftraggeber an seinem eigenen Denkmodell vornehmen kann. Eine Schätzung von 20 Stunden bedeutet nicht, dass die objektiv richtige Dauer dieser Aufgabe 20 Stunden beträgt. Sie bedeutet, dass eine erfahrene Person auf Basis der vor Arbeitsbeginn verfügbaren Informationen rund 20 Stunden erwartet hat. Die Schätzung ist eine Vorhersage unter Unsicherheit, getroffen in dem Moment, in dem am wenigsten über die Aufgabe bekannt war.

Die Forschung zur Expertenschätzung stützt diese Zurückhaltung. Magne Jørgensens Übersicht über Studien zur Expertenschätzung von Softwareentwicklungsaufwänden dokumentiert erhebliche Unsicherheit und Inkonsistenz bei der Aufwandsschätzung, einschließlich Fällen, in denen dieselbe Aufgabe unterschiedlichen Schätzern vorgelegt deutlich abweichende Zahlen ergibt. Das ist eine Eigenschaft der Arbeit, kein Versagen eines einzelnen Teams.

Die praktische Konsequenz verändert das Gespräch. Hören Sie auf, die Schätzung als Beweis dafür zu behandeln, wie lange die Aufgabe hätte dauern müssen, und beginnen Sie, sie als Basislinie für einen Soll-Ist-Vergleich zu nutzen. Weicht das Ist von der Schätzung ab, ist diese Differenz ein Anlass zur Untersuchung, kein Urteil. Die nützliche Frage lautet, worauf das Team während der Arbeit gestoßen ist, das die Schätzung nicht vorhergesehen hatte - und ob es vorher erkennbar gewesen wäre. Ein Dienstleister, der das verlässlich beantwortet, gibt Ihnen etwas Wertvolleres als eine Schätzung, die zufällig stimmt.

Was Softwareentwicklung nach Aufwand transparent macht: von Aufgabe und Schätzung bis Ergebnis und Ist-Stunden

Transparenz in der Softwareentwicklung nach Aufwand ist kein Berichtsformat. Sie ist ein Satz von Artefakten, die zu drei Zeitpunkten existieren - vor der Arbeit, während der Arbeit und nach der Arbeit - und miteinander verbunden bleiben. Wenn alle drei vorhanden sind, wird eine Stundenzahl interpretierbar, weil Sie sehen können, wofür sie aufgewendet wurde, was sie hervorgebracht hat und warum sie vom Plan abweicht. Fehlt auch nur eines davon, reißt die Kette und die Zahl verliert ihren Kontext. Das ist das Rückgrat von allem, was in diesem Artikel folgt.

Vor Arbeitsbeginn sollten für jede Aufgabe nennenswerter Größe diese Punkte vorliegen:

• Aufgabenbeschreibung. Was gebaut oder geändert wird, in einer Sprache, die das Business lesen kann.
• Geschäftlicher Zweck. Warum es sich lohnt. Genau das erlaubt Ihnen später, die Aufgabe ohne Verhandlung zu depriorisieren.
• Schätzung oder Bandbreite. Eine Bandbreite ist meist ehrlicher als ein einzelner Wert, weil sie offenlegt, wie viel Unsicherheit das Team sieht.
• Abnahmekriterien. Die Bedingungen, unter denen die Aufgabe als erledigt gilt. Vorab formulierte Abnahmekriterien verhindern die teuerste Auseinandersetzung in der Softwareentwicklung: die darüber, ob etwas fertig ist.
• Zuständigkeit und Rolle. Welche Rolle die Arbeit übernimmt, denn die Rolle bestimmt den Satz.

Während der Arbeit zählt der sichtbare Status mehr als der Umfang der Berichte:

• Status. Wo die Aufgabe gerade steht - im Tracker, nicht in einer E-Mail.
• Tatsächlicher Verbrauch. Bisher gebuchte Stunden im Verhältnis zur Schätzung. Der Verbrauch ist schlicht das Tempo, in dem das Budget aufgebraucht wird.
• Blocker. Was den Fortschritt aufhält, einschließlich der Punkte, die der Kunde auflösen muss.
• Scope-Änderungen. Alles, was nach dem Start zur Aufgabe hinzukommt, erfasst als Ergänzung statt stillschweigend in die ursprüngliche Position eingerechnet.
• Proaktive Warnung bei wesentlicher Abweichung. Das Team informiert Sie, bevor die Schätzung gerissen wird, nicht danach.

Nach der Arbeit machen die abschließenden Artefakte aus Stunden etwas Bewertbares:

• Ergebnis. Was jetzt existiert, das vorher nicht existierte.
• Ist-Stunden. Gebucht auf die Aufgabe, nicht auf einen Sammeltopf.
• Nachweis. Eine Demo, ein Release, ein Pull Request, ein Testergebnis, ein Design-Artefakt, aktualisierte Dokumentation.
• Erklärung wesentlicher Abweichungen. In Geschäftssprache, für jede Aufgabe, die deutlich von ihrer Schätzung abgewichen ist.

Von Anfang bis Ende gelesen ist das das Modell, auf das dieser Artikel immer wieder zurückkommt: Aufgabe -> Schätzung -> Arbeit -> Nachweis -> Ergebnis -> Ist -> Abweichung. Jedes im Folgenden beschriebene Governance-Instrument hält ein Glied dieser Kette intakt. Eine nützliche Übung: Nehmen Sie Ihre letzte Rechnung und gehen Sie die Kette von einer einzelnen Position aus rückwärts durch. Überall dort, wo Sie das nächste Glied nicht erreichen, haben Sie den Teil des Prozesses gefunden, der Reparatur braucht.

Professionelle Praxisrahmen treffen eine verwandte Unterscheidung. Der Leitfaden des Project Management Institute zum Management externer Softwareentwicklungs-Lieferanten behandelt Lieferantenüberwachung und Abnahme von Leistungen als getrennte Governance-Elemente. Überwachung heißt zu wissen, was passiert, während es passiert. Abnahme heißt zu bestätigen, dass das Gelieferte den vereinbarten Kriterien entspricht. Viele Kunden-Dienstleister-Beziehungen ziehen beides zu einem einzigen monatlichen Ritual zusammen und stellen dann fest, dass keines von beidem tatsächlich stattfindet.

«Mausbewegungen, Screenshots und die Anzahl der Commits sagen für sich genommen nichts über den Wert der Arbeit eines Entwicklers aus. Sechs Stunden für die Suche nach der Ursache eines Produktionsfehlers können am Ende zu einer Änderung von nur drei Codezeilen führen, während ein Tag zur Analyse von Legacy-Code den Ausfall eines kritischen Prozesses verhindern kann. Gleichzeitig können zwanzig Commits und hohe Aktivität Arbeit darstellen, die später wieder zurückgenommen wird. „Aktivität ist kein Output, und Output ist kein Geschäftsergebnis.“ Deshalb sollte ein B2B-Kunde nicht die einzelnen Handlungen des Entwicklers kontrollieren, sondern die gesamte Kette: Aufgabe, Schätzung, erledigte Arbeit, technische Bestätigung, Ergebnis und tatsächlich aufgewendete Zeit. Die Produktivität eines Entwicklers lässt sich nicht objektiv anhand einer einzigen Kennzahl bewerten.»

Andreas Popov

Chief Technology Officer

Stundennachweis prüfen: ein Schritt-für-Schritt-Algorithmus für eine Rechnung über 20 bis 40 Stunden

Das ist das praktische Instrument, wegen dem die meisten Leser hier sind: ein wiederholbares Verfahren, das Sie noch diese Woche auf eine konkrete Rechnung anwenden können, mit den Unterlagen, die Sie ohnehin haben. Für eine typische Monatsabrechnung dauert es etwa dreißig Minuten. Führen Sie es jedes Mal gleich durch, denn die Gleichförmigkeit macht daraus einen Prozess statt einer Auseinandersetzung. Das Ziel ist ein Gespräch mit Struktur - und die Struktur hält das Gespräch produktiv.

Schritt 1 - Schätzung und Ist gegenüberstellen. Holen Sie zu jeder relevanten Position die ursprüngliche Schätzung heraus und stellen Sie sie neben die abgerechnete Zeit. Angenommen, die Schätzung lag bei einer Bandbreite von 16 bis 24 Stunden und das Ist bei 31. Die richtige Frage lautet nicht "Warum 31?", denn damit laden Sie zu einer Verteidigung der gesamten Aufgabe ein. Die Frage lautet: "Wodurch sind die zusätzlichen 7 bis 15 Stunden entstanden?" Diese Fassung fragt nach einer konkreten Differenz, und eine Differenz hat benennbare Ursachen. Machen Sie das für die drei oder vier größten Positionen statt für alle - die kleinen Posten tragen selten die Abweichung, und sie zu verfolgen kostet mehr Aufmerksamkeit, als es einbringt.

Schritt 2 - Die Aufschlüsselung prüfen. Eine Position "CRM-Integration - 38 Std." ist für niemanden prüfbar, auch nicht für den Dienstleister. Dieselbe Arbeit aufgeschlüsselt ist sofort lesbar: API-Recherche 6 Std., Authentifizierung 4 Std., Datenmapping 9 Std., Umsetzung 12 Std., Tests 4 Std., Deployment 3 Std. Jetzt sehen Sie, wo das Gewicht liegt, und Sie können eine gezielte Frage zum schwersten Unterpunkt stellen. Die Aufschlüsselung ist zugleich ein Qualitätssignal für sich, denn ein Team, das eine Aufgabe vor Beginn nicht in Teile zerlegen kann, hat die Aufgabe meist nicht zu Ende gedacht. Wenn Ihre Rechnungen unaufgeschlüsselt eintreffen, beheben Sie das vor allem anderen auf dieser Liste.

Schritt 3 - Scope-Änderung von Mehraufwand trennen. Das sind zwei verschiedene Ereignisse mit verschiedenen Verantwortlichen, und ihre Vermischung ist die häufigste Quelle unnötiger Konflikte. Ein Mehraufwand bedeutet, dass die vereinbarte Arbeit mehr gekostet hat als erwartet. Eine Scope-Änderung bedeutet, dass während der Aufgabe zusätzliche Arbeit hinzukam - oft angefragt von jemandem auf Kundenseite, in einem Chat-Thread, der nie im Tracker gelandet ist. Fragen Sie, welche Teile der abgerechneten Zeit auf Dinge entfallen, die nicht in der ursprünglichen Beschreibung standen. Nach unserer Erfahrung entpuppt sich ein erheblicher Anteil strittiger Stunden als Scope, den der Kunde selbst angefragt und anschließend vergessen hat - eine Governance-Lücke, kein Abrechnungsproblem.

Schritt 4 - Zeit gegen Ergebnis prüfen. Fragen Sie zu jeder relevanten Position, was jetzt existiert, das vorher nicht existierte, und welches Artefakt das belegt. Die Nachweisarten sind bekannt: abgeschlossene Aufgaben im Tracker, Pull Requests, Code-Review-Protokolle, Testergebnisse, ein Release, eine Demo, Design-Artefakte, aktualisierte Dokumentation. Jeder einzelne davon ist mehr wert als eine erzählende Zeiterfassung. Sagen Sie die Grenze klar: Ein Commit ist ein unterstützendes Signal, keine Produktivitätseinheit. Zehn Commits können eine Stunde Arbeit sein, ein Commit können drei Tage sein. Sie prüfen, ob die abgerechnete Zeit in etwas Überprüfbares mündet, nicht ob sie in eine bestimmte Menge von irgendetwas mündet.

Schritt 5 - Erklärung wesentlicher Abweichungen anfordern. Legen Sie den Schwellenwert vorab fest - viele Mittelstandsprojekte arbeiten mit 25 % oder 30 % über dem oberen Ende der Bandbreite - und fordern Sie für alles, was ihn überschreitet, eine Erklärung an. Diese Erklärung sollte aus zwei bis drei Sätzen in klarer Geschäftssprache bestehen: worauf man gestoßen ist, wann es entdeckt wurde, was entschieden wurde und was es gekostet hat. Ein Dienstleister, der mit "Software ist nun einmal unvorhersehbar" antwortet, sagt Ihnen damit, dass er die Ursache nicht nachgehalten hat.

Zwei abschließende Hinweise zur Anwendung. Erstens ist der Algorithmus eine Gesprächsstruktur und kein Verhörleitfaden. Führen Sie ihn mit dem Dienstleister durch, nicht gegen ihn, und sagen Sie offen, dass Sie ihn jeden Monat anwenden, damit niemand überrascht wird. Zweitens funktioniert er am besten, wenn er nichts mehr findet. Der Zweck ist, einen Dokumentationsstandard zu etablieren, der monatliche Funde überflüssig macht. Teams passen sich den Fragen an, die ihnen regelmäßig gestellt werden - und genau diese Anpassung ist der eigentliche Ertrag der dreißig Minuten. Derselbe Maßstab - Nachweise zuerst - gilt für jede Fachleistung, die Sie nach Stunden einkaufen, vom Security-Review bis zum Site Audit: Verlangen Sie Befunde, keine Stunden.

Wann ein Stundenmehraufwand objektiv gerechtfertigt ist

Ein solcher Abschnitt gehört in jede ehrliche Behandlung des Themas, denn ein Artikel, der nur Warnsignale auflistet, trainiert den Leser darauf, in jeder Abweichung ein Problem zu sehen. Die meisten Mehraufwände kompetenter Teams haben eine konkrete, benennbare technische Ursache - und die geschäftliche Folge, sie alle als verdächtig zu behandeln, ist, dass das Team sie nicht mehr frühzeitig meldet. Entscheidend ist nicht, ob der Mehraufwand entstanden ist. Entscheidend ist, ob er erklärt wurde und wann.

Dies sind die Ursachen, die uns in Mittelstandsprojekten am häufigsten begegnen:

• Undokumentierter Legacy-Code. Das Verhalten muss durch Lesen und Experimentieren rekonstruiert werden, bevor es gefahrlos geändert werden kann.
• Undokumentiertes API-Verhalten. Das Partnersystem tut etwas, das seine Spezifikation nicht erwähnt, und die Umgehungslösung muss entworfen und getestet werden.
• Eine verdeckte Abhängigkeit. Die Änderung an einem Modul wirkt sich auf ein anderes aus, das niemand damit in Verbindung gebracht hatte.
• Probleme bei der Datenmigration. Echte Produktionsdaten enthalten Zustände, die das Schema für unmöglich hält.
• Versionsinkompatibilität. Ein Upgrade von Bibliothek, Runtime oder Plattform ist erforderlich, bevor die eigentliche Aufgabe fortgesetzt werden kann.
• Sicherheits- oder Stabilitätsprobleme, die mitten in der Aufgabe auftauchen. Eine Lücke in der Zugriffskontrolle oder eine Race Condition, die man auf dem Weg zu etwas anderem findet und die jetzt günstiger zu beheben ist als später.
• Geänderter Scope. Die Anforderung ist während der Arbeit gewachsen, unabhängig davon, wer sie angestoßen hat.
• Zusätzlicher Testbedarf. Die Änderung berührt einen geschäftskritischen Pfad und verdient mehr Prüfung als ursprünglich geplant.
• Eine anfängliche Annahme, die sich als falsch erwies. Der zum Schätzzeitpunkt gewählte Ansatz übersteht den Kontakt mit dem System nicht, und ein anderer wird nötig.

Zwei kurze Szenarien machen die Kategorie greifbar. Ein mittelständischer Distributor wünscht eine bidirektionale Synchronisation zwischen CRM und Auftragssystem, geschätzt mit 20 Stunden. Die CRM-API liefert einen Erfolgscode für Aktualisierungen zurück, die sie stillschweigend verwirft, sobald ein benutzerdefiniertes Feld leer ist - nirgends dokumentiert. Dieses Verhalten zu erkennen, nachzuweisen und eine Verifikationsstufe darum herum zu bauen, kostet 11 zusätzliche Stunden. Ein anderes Beispiel: Ein Fertigungsunternehmen modernisiert ein internes Portal von 2013 und wünscht eine neue Auswertungsmaske. Die Auswertungsabfrage hängt von einem nächtlichen Job ab, auf den sich eine andere Abteilung für die Rechnungsstellung verlässt, sodass die Änderung abgestimmt und gegen diesen Job getestet werden muss. Keines der beiden Teams hat schlecht geschätzt. Beide sind auf eine Tatsache gestoßen, die vor Arbeitsbeginn nicht sichtbar war.

Was diese Fälle von einem Governance-Versagen unterscheidet, sind Zeitpunkt und Offenlegung. In beiden Szenarien ist das richtige Verhalten, das Thema am Tag der Entdeckung anzusprechen, die erwarteten Zusatzkosten zu nennen und den Kunden zu fragen, ob fortgesetzt, vereinfacht oder gestoppt werden soll. Ein im Moment der Entdeckung offengelegter Mehraufwand ist ein Projektereignis, auf das das Unternehmen reagieren kann. Derselbe Mehraufwand, dreißig Tage später in einer Rechnung offengelegt, ist ein Verlust, den das Unternehmen nur noch schlucken kann. Dieser Unterschied - nicht die Stunden selbst - trennt einen reifen Partner von einem problematischen.

Neun Anzeichen, dass bei der Abrechnung nach Aufwand tatsächlich etwas nicht stimmt

Der vorige Abschnitt hat eine einzelne Rechnung geprüft. Dieser diagnostiziert den Lieferprozess dahinter, was eine andere Übung mit einem anderen Zeithorizont ist. Prozessprobleme zeigen sich nicht in einem Dokument; sie zeigen sich als Muster über mehrere Monate. Lesen Sie die folgende Liste gegen Ihr letztes Quartal statt gegen Ihre letzte Abrechnung. Es sind Signale dafür, wie die Arbeit organisiert ist, und jedes davon lässt sich beheben, wenn man es früh benennt.

1. Selbst für umfangreiche Aufgaben gibt es keine Schätzung. Ohne Basislinie gibt es keine Abweichung, und ohne Abweichung gibt es nichts zu besprechen. Ein Team, das nicht schätzen will, ist ein Team, das man an nichts messen kann.
2. Große Aufgaben werden nie aufgeschlüsselt. Positionen im Umfang von Dutzenden Stunden kommen als einzelne Zeile an. Das verbirgt sowohl Kosten als auch Risiko und bedeutet meist, dass die Planung während der Arbeit stattfindet statt davor.
3. Ein wesentlicher Mehraufwand taucht erst in der Rechnung auf. Das schädlichste Muster dieser Liste, weil es dem Kunden die Möglichkeit nimmt, zu entscheiden, solange eine Entscheidung noch etwas bewirkt.
4. Zeiterfassungen lauten "Entwicklung - 8 Std.". Allgemeine Einträge, die jede Arbeit in jedem Projekt beschreiben könnten. Die Korrektur ist günstig, und der Widerstand dagegen ist aufschlussreich.
5. Das Team erklärt die Ursachen von Abweichungen nicht. Mehraufwände werden eingeräumt, aber nie zugeordnet. Niemand lernt etwas, und dieselbe Ursache wiederholt sich im nächsten Quartal.
6. Es gibt keine Verbindung zwischen Zeit und konkreten Backlog-Einträgen. Stunden werden auf das Projekt gebucht statt auf Aufgaben, sodass sich Ausgaben nicht mit Prioritäten verknüpfen lassen.
7. Der Kunde sieht nie das tatsächliche Ergebnis der Arbeit. Keine Demos, kein Zugang zu einer laufenden Umgebung, keine Releases, die man ansehen kann. Fortschritt existiert nur als Beschreibung.
8. Nacharbeit wird routinemäßig abgerechnet, ohne über die Ursache zu sprechen. Ein gewisses Maß an Nacharbeit ist normal und eingeplant. Regelmäßige Nacharbeit ohne Analyse, warum sie immer wieder auftritt, bedeutet, dass derselbe Prozessfehler wiederholt bezahlt wird.
9. Es gibt keine belastbare Budgetprognose und keinen Restaufwand. Das Team kann sagen, was ausgegeben wurde, aber nicht, was die Fertigstellung kosten wird. Die Berichterstattung blickt ausschließlich zurück.

Wie Sie Ihr eigenes Ergebnis lesen sollten: Ein Signal ist ein Gesprächsthema für das nächste Review, und die meisten Projekte haben irgendwann eines. Zwei Signale, die gemeinsam auftreten, haben in der Regel dieselbe Ursache, und sie zu benennen genügt oft. Drei oder mehr sind ein Governance-Problem, das sich nicht von selbst löst, weil jedes fehlende Element die Information entzieht, die zur Behebung der anderen nötig wäre. An diesem Punkt ist der sinnvolle Schritt, die Arbeitsvereinbarung neu aufzusetzen - Regeln zur Aufschlüsselung, Berichtsformat, Eskalationsschwellen - und nicht, den Ton der monatlichen E-Mail zu verschärfen.

Projektkosten der Softwareentwicklung kontrollieren, ohne das Team zu mikromanagen

Das Ziel ist Sichtbarkeit der Ausgaben, und Sichtbarkeit ist nicht dasselbe wie Überwachung. Überwachung erzeugt defensives Verhalten, bremst die Lieferung und sagt Ihnen nichts darüber, ob das Geld die richtigen Dinge kauft. Gute Governance arbeitet auf der Ebene der Zusammenarbeit statt auf der Ebene der einzelnen Person: Sie legt den Rhythmus fest, in dem Informationen eintreffen, die Schwellen, an denen das Unternehmen eine Entscheidung bekommt, und die Grenzen, jenseits derer die Arbeit ohne Freigabe nicht weiterläuft. Sechs Instrumente decken nahezu alles ab, und keines davon verlangt, dass jemand einem Entwickler bei der Arbeit zusieht. Dieselben Instrumente lassen sich auf jedes andere Retainer-Modell nach Stunden übertragen, auch auf Online Marketing, wo das monatliche Volumen genauso schwankt.

Soll-Ist-Vergleich als Trend

Eine einzelne Aufgabe, die 60 % über ihrer Schätzung lag, sagt sehr wenig aus, und ein Team, das nie überschreitet, puffert vermutlich. Sehr viel aussagekräftiger ist die Verteilung über dreißig oder fünfzig Aufgaben: ob sich Über- und Unterschreitungen ungefähr ausgleichen, ob die Streuung enger wird, während das Team Ihr System kennenlernt, und ob bestimmte Arbeitskategorien systematisch unterschätzt werden. Verfolgen Sie den Trend monatlich als Gesundheitsindikator, nicht als Bewertungsraster. Eine stabile, leicht konservative Schätzhistorie ist eines der stärksten Signale für ein Team, das versteht, woran es arbeitet.

Wöchentliches oder zweiwöchentliches Budget-Review

Die Monatsrechnung ist der denkbar schlechteste Zeitpunkt, um von Ausgaben zu erfahren, denn bis dahin ist jede Entscheidung, die sie hätte beeinflussen können, bereits gefallen. Ein kurzes Review alle ein bis zwei Wochen - zwanzig Minuten, gebuchte Stunden gegen Plan, was sich geändert hat, was kommt - hält die Zahl klein genug, um noch handeln zu können. Verankern Sie den Rhythmus in der Arbeitsvereinbarung, statt auf guten Willen zu vertrauen, denn genau in den Wochen, in denen das Review am wichtigsten ist, haben alle am wenigsten Zeit dafür. Im Review werden außerdem Scope-Änderungen erfasst, bevor jemand vergisst, wer sie angefragt hat.

Restaufwand und Prognose

Ist-Stunden blicken zurück. Was ein Unternehmen zur Planung braucht, ist der Blick nach vorn: der Restaufwand, also die aktuelle Erwartung des Teams, was zur Fertigstellung des vereinbarten Scope noch erforderlich ist, und eine Prognose der Kosten der kommenden Periode. Beides sollte im Verlauf der Arbeit aktualisiert werden, denn ein zu Beginn erstellter und nie fortgeschriebener Restaufwand ist nur der ursprüngliche Plan unter anderem Namen. Fordern Sie die Prognose in jeder Periode im gleichen Format an, damit Sie ihre Bewegung verfolgen können. Eine Prognose, die stillschweigend immer weiter steigt, ist eine Information; eine Prognose, die erst auf Nachfrage existiert, ist ein Warnsignal aus dem vorigen Abschnitt.

Schwellenwert-Meldungen beim Budget

Vereinbaren Sie im Voraus eine Abweichung, bei der das Team anhalten und Sie benachrichtigen muss - einen Prozentsatz über der Aufgabenschätzung oder einen absoluten Betrag auf das Iterationsbudget. Wird die Schwelle überschritten, besteht die Pflicht des Teams darin, dies zu melden und eine Entscheidung einzuholen. Diese eine Regel verändert die Form der gesamten Zusammenarbeit, denn sie macht aus der Eskalation etwas, das der Dienstleister schuldet, statt etwas, das der Kunde entdecken muss. Schreiben Sie sie mit einer Zahl in die Vereinbarung. "Das Team hält uns auf dem Laufenden" ist kein Schwellenwert.

Capped Time & Materials und Not-to-Exceed

Capped Time & Materials behält die Abrechnung nach Aufwand bei, ergänzt sie aber um eine Obergrenze: Der Kunde bezahlt die tatsächlichen Stunden bis zu einem vereinbarten Maximum für eine Iteration, eine Phase oder einen definierten Aufgabenumfang, und die Arbeit läuft über diese Grenze hinaus nicht ohne neue Entscheidung weiter. Eine Not-to-Exceed-Klausel erfüllt denselben Zweck in Vertragssprache. Die Konstruktion gibt dem Unternehmen die Budgetsicherheit, die es sich vom Festpreis erhofft, und erhält zugleich die Flexibilität und Sichtbarkeit der Aufwandsabrechnung. Sie ist eine übliche kaufmännische Vereinbarung und kein ungewöhnliches Zugeständnis. Die Preisseite von ScienceSoft führt Capped Time & Materials unter den Standardmodellen auf - eine nützliche Referenz, falls Sie auf Widerstand stoßen. Ein Zielkonflikt gehört dazu: Eine für den Umfang zu niedrig gesetzte Obergrenze führt entweder zu reduziertem Scope oder zu einer Nachverhandlung, weshalb sie bei klar abgegrenzten Iterationen am besten funktioniert.

Stopp- und Weiter-Checkpoints

Ein Checkpoint ist ein geplanter Moment - das Ende einer Iteration, ein Meilenstein, ein festgelegter Punkt des Budgetverbrauchs - an dem die Arbeit nicht automatisch weiterläuft. Dort kann der Kunde wie geplant fortfahren, das Backlog neu priorisieren, den Scope kürzen, eine kurze Discovery zur Reduktion der Unsicherheit einschieben, den technischen Ansatz wechseln oder die Arbeit vollständig beenden. Der Wert liegt darin, die Option zu besitzen, nicht darin, sie zu ziehen - denn eine Zusammenarbeit mit echten Haltepunkten ist eine, in der die Verhandlungsposition des Kunden nicht vom Wohlwollen des Dienstleisters abhängt.

Zusammengenommen bewirken diese sechs Instrumente eines: Sie bringen Informationen früh genug zum Kunden, um nützlich zu sein, ohne dass jemand einen Bildschirm beobachtet. Mehr ist Budgetkontrolle in der Softwareentwicklung nach Aufwand nicht. Die Projekte, die schieflaufen, sind selten die, in denen das Team langsam war. Es sind die, in denen niemand einen Schwellenwert gesetzt hat, niemand ein Review angesetzt hat und das erste ernsthafte Gespräch über Geld erst stattfand, als das Geld weg war.

«Wenn ein Unternehmen frühzeitig erkennt, dass eine Aufgabe den geschätzten Aufwand überschreitet, kann es die Kosten noch beeinflussen: die Lösung vereinfachen, das Budget neu verteilen, einen Teil der Arbeiten verschieben oder die Aufgabe stoppen. Deshalb verstehen wir Transparenz nicht als nachträgliche Berichterstattung, sondern als Instrument für Entscheidungen während der Entwicklung. Der Scrum Guide beschreibt dies mit den Begriffen „Transparenz, Inspektion, Anpassung“ und betont: „Inspektion ohne Transparenz ist irreführend und Verschwendung.“ Eine monatliche Rechnung zeigt, was bereits passiert ist, während Transparenz es ermöglicht, zu beeinflussen, was als Nächstes passiert.»

Andreas Popov

Chief Technology Officer

Welche Kennzahlen helfen und welche nur ein falsches Gefühl von Kontrolle erzeugen

Jede Kennzahl, die ein Unternehmen verfolgt, ist zugleich eine Anweisung an das Team, worauf es optimieren soll. Deshalb sind die falschen Kennzahlen schlimmer als gar keine. Die folgenden Kennzahlen teilen sich in zwei Gruppen: solche, die die Lieferung beschreiben und eine Entscheidung stützen können, und solche, die Aktivität beschreiben und das nicht können. Die zweite Gruppe ist nicht verboten. Sie ist nur nicht in der Lage, das Gewicht zu tragen, das Auftraggeber ihr häufig zumuten - und der Schaden entsteht, sobald eine Aktivitätszahl zur Grundlage einer Bewertung wird.

Die linke Spalte teilt eine Eigenschaft: Jeder Punkt beschreibt den Arbeitsfluss oder dessen Ergebnis, sodass eine Verbesserung der Zahl eine Verbesserung der Lieferung voraussetzt. Die Cycle Time sinkt, wenn Übergaben und Blocker beseitigt werden. Nacharbeit sinkt, wenn Anforderungen und Reviews besser werden. Fehler sinken, wenn ausreichend getestet wird. Diese Kennzahlen sind schwer zu manipulieren, weil der günstigste Weg, sie zu bewegen, darin besteht, die Arbeit besser zu machen.

Die rechte Spalte teilt die gegenteilige Eigenschaft: Jeder Punkt misst beobachtbare Aktivität, und jeder einzelne lässt sich steigern, ohne dass etwas entsteht. Commits lassen sich aufteilen. Tickets lassen sich zerschneiden. Tastaturaktivität lässt sich erzeugen. Das ist der Kern der Argumentation im SPACE-Framework: Entwicklerproduktivität ist mehrdimensional, keine einzelne Kennzahl bildet sie ab, und die Optimierung auf eine Dimension verzerrt das Verhalten in den anderen. Ein Team, das an der Commit-Zahl gemessen wird, wird Commits produzieren. Ob es funktionierende Software produziert, ist eine andere Frage, die diese Kennzahl nicht beantworten kann.

Ein praktischer Auswahltest: Fragen Sie sich bei jeder Zahl, die Sie verfolgen wollen, welche Entscheidung Sie treffen würden, wenn sie sich um 30 % bewegt. Fällt die Antwort konkret aus - neu priorisieren, eine Person ergänzen, einen Engpass untersuchen, den Ansatz ändern - verdient die Kennzahl ihren Platz. Lautet die Antwort "Ich würde das Team danach fragen", haben Sie einen Gesprächsanlass und kein Steuerungsinstrument.

Brauchen Sie eine Zeiterfassung mit Screenshots

Die direkte Antwort: Eine Zeiterfassung mit Screenshots kann in bestimmten Arbeitsmodellen ein unterstützendes Werkzeug sein, und sie darf nicht die Grundlage für die Bewertung von Wissensarbeit sein. Echten Nutzen bringt sie in kurzen, transaktionalen Beauftragungen mit unbekannten Einzelkontraktoren oder dort, wo ein bestehender Compliance-Prozess einen Aktivitätsnachweis verlangt. Selbst dort belegt sie Anwesenheit statt Wert - und Anwesenheit stand nie in Frage.

Diese Frage dominiert die deutschsprachigen Suchergebnisse rund um Projektzeiterfassung und Abrechnung nach Aufwand, deshalb verdient sie eine klare Antwort statt eines Ausweichmanövers. Eine strukturierte Zeiterfassung auf Aufgabenebene ist tatsächlich wertvoll: Sie ist es, die Stunden mit Backlog-Einträgen verbindet, Schätzung und Ist vergleichbar macht und eine Prognose ermöglicht. Das ist etwas anderes als eine Bildschirmaufzeichnung. Zeit auf eine Aufgabe zu buchen erzeugt Information, auf die ein Unternehmen reagieren kann. Alle zehn Minuten einen Screenshot zu erfassen erzeugt ein Archiv, das niemand sichtet - und es verursacht Kosten, die in Ihrer Rechnung als der Aufwand für seine Verwaltung auftauchen.

Die stärkere Position für einen Auftraggeber ist, stattdessen die Artefakte einzufordern. Verlangen Sie aufgeschlüsselte Aufgaben, Schätzungen, Tracker-Zugang, Ergebnisnachweise und Erklärungen von Abweichungen. Ein Team, das diese liefert, ist lesbar, ganz gleich ob jemand Screenshots erstellt. Ein Team, das Screenshots liefert und sonst nichts, hat Ihnen sehr viele Daten und keine Information gegeben.

Schützt der Festpreis besser vor Überzahlung als Time & Materials

Die direkte Antwort lautet: nein, nicht zwangsläufig - und die Begründung zählt mehr als das Urteil. Der Festpreis fühlt sich sicherer an, weil er eine offene Zahl in eine geschlossene verwandelt, und eine geschlossene Zahl lässt sich intern leichter freigeben. Was er nicht leistet, ist, die zugrunde liegende Unsicherheit darüber zu beseitigen, wie viel Arbeit die Software tatsächlich erfordert. Diese Unsicherheit muss irgendwohin, und beim Festpreis wandert sie an Stellen, die für einen Auftraggeber schwerer zu prüfen sind als eine Stundenzahl.

Bei Time & Materials liegt das Risiko einer falschen Schätzung an der Oberfläche. Sie sehen es als Stunden, in der Periode, in der sie angefallen sind, verbunden mit der Aufgabe, die sie verursacht hat. Das ist unangenehm und es ist sichtbar - und sichtbares Risiko lässt sich mit den weiter oben beschriebenen Instrumenten steuern. Beim Festpreis wandert dasselbe Risiko in einen eingepreisten Risikopuffer des Dienstleisters, in harte Scope-Grenzen, die jede Klärung zu einer Verhandlung machen, in einen Change-Request-Prozess mit eigener kaufmännischer Dynamik, in vereinfachte technische Lösungen zum Schutz der Marge des Dienstleisters und im schlimmsten Fall in Qualitätskompromisse an genau den Stellen des Systems, die der Kunde am wenigsten beurteilen kann.

Achten Sie auf die letzte Zeile der Tabelle, denn sie ist der Punkt des gesamten Vergleichs. Beide Modelle scheitern, sie scheitern auf unterschiedliche Weise, und in beiden Fällen ist das Scheitern ein Governance-Versagen und kein Preisproblem. Das Preismodell entscheidet, wo Sie hinschauen müssen. Es entscheidet nicht, ob Sie hinschauen müssen.

Die praktische Schlussfolgerung lautet also nicht "Wählen Sie dieses hier". Sie lautet: Ein Unternehmen, das keine Abnahmekriterien, keinen Berichtsrhythmus, keine Eskalationsschwellen und keinen Entscheidungsprozess definiert hat, wird in beiden Modellen zu viel bezahlen. Ein Unternehmen, das sie definiert hat, kann beide Modelle erfolgreich fahren und wird in der Regel Time & Materials für sich entwickelnde Arbeit und den Festpreis für klar abgegrenzte Arbeit bevorzugen - was genau das Thema des nächsten Abschnitts ist.

Wann sich Softwareentwicklung nach Aufwand für den Mittelstand eignet

Die Frage nach der Passung hat eine verlässliche Antwort, und sie hängt weder von der Unternehmensgröße noch vom Budget ab. Sie hängt davon ab, wie viel zu Beginn unbekannt ist und wie viel sich während der Arbeit voraussichtlich ändert. Wo die Unsicherheit hoch ist, ist die Abrechnung nach Aufwand das ehrliche Modell, und der Festpreis wird zu einem teuren Weg, das Gegenteil zu behaupten. Wo die Arbeit wirklich klar definiert und stabil ist, ist eine feste Summe für alle Beteiligten einfacher, und es gibt keinen Grund, sie zu meiden.

Time & Materials ist in diesen Situationen meist die richtige Wahl:

• SaaS-Produktentwicklung. Die Richtung ändert sich mit dem Marktfeedback, und die Roadmap, auf die Sie sich im Januar festlegen, ist nicht die, die Sie im Juni bauen sollten.
• Weiterentwicklung eines bestehenden CRM oder ERP. Das System hat bereits Nutzer, Daten und Abhängigkeiten, und der tatsächliche Umfang zeigt sich erst während der Arbeit.
• Komplexe Integrationen. Das Verhalten der Systeme auf der Gegenseite ist im Voraus nur teilweise bekannt.
• Legacy-Modernisierung. Unsicherheit ist die definierende Eigenschaft dieser Arbeit, denn die Codebasis ist die Spezifikation.
• KI-Funktionalität. Die Ergebnisse hängen von der Datenqualität und von Experimenten ab, die sich vorab nicht präzise terminieren lassen.
• Ein sich entwickelndes Backlog. Prioritäten werden alle paar Wochen an den Geschäftsergebnissen neu bewertet.
• Langfristige Entwicklung einer Unternehmensplattform. Die Zusammenarbeit überdauert jedes Scope-Dokument, das sich dafür schreiben ließe.
• Support und kontinuierliche Verbesserung. Das Volumen schwankt naturgemäß von Monat zu Monat.

Schwächer passt das Modell bei klar abgegrenztem, stabilem Scope, bei dem beide Seiten das fertige Ergebnis vor dem Start im Detail beschreiben können: eine Marketing-Website, eine definierte Migration, ein abgeschlossenes Modul mit klarer Spezifikation und ohne Abhängigkeit von Vorstudien. In diesen Fällen ist ein Festpreis oder eine hybride Vereinbarung - Festpreis für den definierten Kern, Aufwand für die Teile, die von Erkenntnissen abhängen - für alle Beteiligten oft bequemer. Eine Marketing-Website dieser Art ist Routinearbeit für eine Webdesign Agentur in Deutschland und lässt sich zuverlässig zum Festpreis kalkulieren.

Die Entscheidungsregel, die wir Kunden mitgeben, besteht aus drei Fragen. Wie stabil ist der Scope über die erwartete Dauer der Arbeit? Wie viel ist zu Beginn tatsächlich unbekannt, insbesondere über Systeme und Daten, die Sie nicht kontrollieren? Wie lang ist die Zusammenarbeit angelegt, denn längere Projekte sammeln Veränderung an, egal wie fest der ursprüngliche Plan aussah? Hohe Stabilität, wenige Unbekannte und ein kurzer Horizont sprechen für den Festpreis. Zwei gegenteilige Antworten sprechen für Time & Materials mit ordentlicher Governance - und eine Obergrenze je Iteration erfüllt in der Regel jedes Bedürfnis nach Budgetsicherheit, das das Unternehmen hat.

Checkliste: Was Sie mit dem IT-Dienstleister vor Beginn der Abrechnung nach Aufwand vereinbaren sollten

Alles in diesem Artikel lässt sich vor dem Start der Zusammenarbeit leichter etablieren als nach der ersten strittigen Rechnung. Die folgende Liste ist so geschrieben, dass Sie sie in ein Dienstleistergespräch mitnehmen und Punkt für Punkt durchgehen können. Ein kompetenter Partner hat auf das meiste davon bereits Antworten und wird die Fragen nicht als ungewöhnlich empfinden. Rechnen Sie mit einer Stunde Gespräch. Diese Stunde ist die günstigste Governance, die Sie je kaufen werden, und wie ein Dienstleister darauf reagiert, sagt Ihnen so viel wie die Antworten selbst.

Kaufmännische Konditionen

• Stundensätze nach Rolle, mit namentlich benannten Rollen.
• Wer Stunden auf das Projekt buchen darf und wer die Aufnahme einer weiteren Person freigibt.
• Was als abrechenbare Arbeit gilt, ausdrücklich festgehalten.
• Wie QA, Code Review und Meetings gezählt werden.
• Regeln zur Nacharbeit: was abrechenbar ist, was nicht und wer entscheidet.

Schätzung und Scope

• Regeln zur Aufwandsschätzung: welche Aufgaben geschätzt werden und zu welchem Zeitpunkt.
• Das Format einer Schätzung - Einzelwert oder Bandbreite, und was die Bandbreite bedeutet.
• Verantwortung für das Backlog und wer die Prioritätenreihenfolge festlegt.
• Abnahmekriterien: wer sie schreibt und wann sie vorliegen müssen.

Berichterstattung und Transparenz

• Format des Stundennachweises, einschließlich des Detailgrads je Eintrag.
• Berichtsrhythmus, mit Terminen statt Absichtserklärungen.
• Zugang zum Projekt-Tracker für Ihr Team, mindestens lesend.
• Zugang zu den Arbeitsergebnissen: Umgebungen, Releases, Pull Requests, Dokumentation.

Budget-Governance

• Wann das Team eine Abweichung melden muss, ausgedrückt als Zahl.
• Der Budgetschwellenwert, der eine Benachrichtigung und eine Kundenentscheidung auslöst.
• Eine Budgetobergrenze je Iteration oder Phase, falls Sie eine wünschen.
• Restaufwand und Prognose sowie die Frequenz ihrer Aktualisierung.
• Ein regelmäßiger Plan-Ist-Abgleich, im Voraus terminiert.

Zwei Hinweise zur Nutzung der Checkliste. Sie brauchen bei einem kleinen Projekt nicht jeden Punkt, und auf allen achtzehn für ein dreiwöchiges Arbeitspaket zu bestehen, kostet mehr Aufmerksamkeit, als es einspart. Wählen Sie die Punkte, die zu Größe und Dauer Ihres Vorhabens passen, und ergänzen Sie den Rest, wenn die Zusammenarbeit wächst. Der zweite Hinweis wiegt schwerer: Vereinbaren Sie diese Punkte schriftlich, in welchem Dokument auch immer die Beziehung geregelt ist. Ein mündliches Einvernehmen über Eskalationsschwellen hält exakt bis zu dem Monat, in dem Eskalieren unbequem wird. Die Größe zählt dabei weniger als gedacht: Ein kurzes Mandat für Beauty Salon SEO in Deutschland verdient dieselben schriftlichen Schwellen wie ein einjähriger Plattformaufbau.

Wie ein reifer IT-Partner Transparenz in Lieferung und Budget verankert

Das Problem an Time & Materials ist in aller Regel nicht das Stundenmodell. Es ist das Fehlen eines Prozesses darum herum. Das Modell selbst ist neutral: Es rechnet Zeit ab, und ob diese Zeit lesbar ist, hängt vollständig von den Artefakten ab, die das Team währenddessen erzeugt. Jedes Instrument in diesem Artikel - Aufschlüsselung, Schätzungen, Schwellenwerte, Prognosen, Nachweise - liegt in der Verantwortung des Dienstleisters, und der Kunde sollte sich darauf verlassen können, ohne danach fragen zu müssen.

Bei Webdelo entwickeln wir B2B-Plattformen, ERP- und CRM-Systeme, FinTech-Tools, Integrationen und High-Load-Services für mittelständische Unternehmen in den USA, Deutschland und Osteuropa - und wir arbeiten seit 2006 auf diese Weise. In Aufwandsprojekten ist die Prozessseite der Arbeit ausdrücklich geregelt. Wir schlüsseln Aufgaben auf, bevor wir sie schätzen, sodass die Schätzung eine prüfbare Struktur hat statt einer einzelnen Zahl, die Sie hinnehmen müssen. Wir schätzen in Bandbreiten, die die reale Unsicherheit abbilden. Wir halten das Backlog für den Kunden sichtbar und erwarten, dass der Kunde die Prioritätenreihenfolge verantwortet, denn in der Priorisierung wird das Geld tatsächlich gesteuert. Wir eskalieren Abweichungen, wenn wir sie feststellen, nicht wenn wir sie abrechnen. Wir liefern eine Prognose neben den Ist-Werten, damit das Gespräch die kommende Periode betrifft und nicht nur die vergangene. Jede Stunde hängt an einer Aufgabe, und jede Aufgabe hängt an etwas, das Sie sich ansehen können: einem Release, einer Umgebung, einem Pull Request, einem Testergebnis, einem Dokument. Derselbe Prozess gilt auch dann, wenn es um gewöhnliche Webentwicklung in Deutschland geht und nicht um eine komplexe Plattform.

Der Teil, der für ein mittelständisches Unternehmen am meisten zählt, liegt oberhalb der Umsetzungsmechanik. Scope ist eine Budgetentscheidung, und der größte Teil der Einsparungen in einem Softwareprojekt entsteht aus der Entscheidung, was nicht gebaut wird, und nicht aus der Verhandlung über den Satz für das, was gebaut wird. Wir erwarten, Teil dieses Gesprächs zu sein: welche Punkte echten geschäftlichen Wert tragen, welche ein Quartal warten können, welche sich mit einer einfacheren Lösung zu einem Bruchteil der Kosten erfüllen lassen und an welcher Stelle eine kurze Discovery genug Unsicherheit beseitigt, um den Rest der Arbeit planbar zu machen.

Das ist die Rolle, die ein IT-Partner aus unserer Sicht für ein mittelständisches Unternehmen einnehmen sollte: Lieferung, Risiko und IT-Investition mitsteuern, mit dem Stundenmodell als Abrechnungsmechanik und nicht als Beziehungsmodell. Transparenz ist das, was die Zusammenarbeit in beide Richtungen funktionieren lässt. Sie gibt dem Kunden die Informationen, um während der Umsetzung zu entscheiden, und sie gibt dem Team die Freiheit, Probleme sauber zu lösen, ohne an Aktivität gemessen zu werden.

Häufige Fragen

Lässt sich tatsächlich überprüfen, ob ein Entwickler wirklich 20 Stunden gearbeitet hat?

Nicht direkt, und kein Überwachungswerkzeug ändert daran etwas. Überprüfbar ist die Kette um diese Stunden herum: die Aufgabe, auf die sie gebucht wurden, die Schätzung, an der sie gemessen werden, der erbrachte Nachweis, das gelieferte Ergebnis und die Erklärung jeder wesentlichen Abweichung. Ist diese Kette vollständig, wird die Stundenzahl interpretierbar.

Wie viele Stunden sollte eine typische Entwicklungsaufgabe dauern?

Es gibt keine Branchennorm, weil dieselbe Funktion in verschiedenen Systemen unterschiedlich viel kostet. Die Kosten werden vom Zustand der Codebasis, von Legacy-Komponenten, der Qualität der Dokumentation, Integrationen, der Testtiefe und Infrastrukturabhängigkeiten bestimmt. Ihre Rechnung mit dem zu vergleichen, was ein anderes Unternehmen für eine ähnlich benannte Aufgabe bezahlt hat, erzeugt Rauschen statt Erkenntnis.

Was tue ich, wenn das Ist die Schätzung deutlich überschreitet?

Fragen Sie, wodurch die Differenz entstanden ist, statt warum die Gesamtsumme so hoch ist, denn eine Differenz hat benennbare Ursachen. Trennen Sie anschließend den während der Arbeit hinzugekommenen Scope von einer falschen Schätzung, denn das sind verschiedene Ereignisse mit verschiedenen Verantwortlichen. Vereinbaren Sie schließlich einen Schwellenwert, ab dem künftige Abweichungen gemeldet werden müssen, bevor die Arbeit weiterläuft.

Sollte ein IT-Dienstleister einen detaillierten Stundennachweis liefern?

Ja, auf Aufgabenebene und nicht auf Minutenebene. Die Einträge sollten mit konkreten Backlog-Einträgen verknüpft sein, damit sich Zeit mit Schätzungen und gelieferten Ergebnissen vergleichen lässt. Allgemeine Zeilen wie "Entwicklung - 8 Std." sind für die Steuerung unbrauchbar und sollten als zu behebende Prozesslücke behandelt werden.

Ist es normal, Meetings, QA und Code Review abzurechnen?

Ja. Anforderungsklärung, Testen und Code Review gehören zur Erstellung funktionierender Software, und sie zu streichen macht ein Projekt riskanter statt günstiger. Entscheidend ist, dass die Regeln vor Beginn der Zusammenarbeit vereinbart sind und dass diese Zeit transparent erfasst wird.

Kann man Entwickler ohne Screenshots steuern?

Ja, und es funktioniert sogar besser. Eine strukturierte Zeiterfassung auf Aufgabenebene, aufgeschlüsselte Schätzungen, Tracker-Zugang, Ergebnisnachweise und Erklärungen von Abweichungen geben einem Unternehmen alles, was es für Entscheidungen braucht. Bildschirmaufzeichnung misst Anwesenheit, und die stand selten zur Debatte.

Was ist Capped Time & Materials?

Es ist die Abrechnung nach Aufwand mit einer Obergrenze. Der Kunde bezahlt die tatsächlichen Stunden bis zu einem vereinbarten Maximum für eine Iteration, eine Phase oder einen definierten Umfang, und die Arbeit läuft über diese Grenze hinaus nicht ohne neue Entscheidung weiter. Das Modell verbindet die Flexibilität und Sichtbarkeit der Aufwandsabrechnung mit der Budgetsicherheit, die sich die meisten Unternehmen vom Festpreis wünschen.

Was ist für den Mittelstand besser: Festpreis oder Time & Materials?

Das hängt davon ab, wie stabil der Scope ist und wie viel zu Beginn unbekannt ist. Klar abgegrenzte, planbare Arbeit passt zum Festpreis; sich entwickelnde Produkte, Integrationen, Legacy-Modernisierung und langfristige Entwicklung passen zu Time & Materials mit einer Obergrenze je Iteration. Kein Modell ersetzt Governance.

Fazit: Prüfen Sie die Kette, nicht die Stunde

Der Kerngedanke dieses Leitfadens lässt sich in einen Satz fassen: Eine Stunde können Sie nicht prüfen, eine Kette schon. Softwareentwicklung nach Aufwand wird in dem Moment steuerbar, in dem ein Unternehmen aufhört, über einzelne Zahlen zu streiten, und anfängt, die Artefakte einzufordern, die Zahlen aussagekräftig machen - die Aufgabe, die Schätzung, die Arbeit, den Nachweis, das Ergebnis, das Ist und den Grund für die Abweichung. Jedes oben beschriebene Governance-Instrument existiert, um ein Glied dieser Kette intakt zu halten.

Drei Dinge lohnt es mitzunehmen. Bauen Sie Nachvollziehbarkeit auf, bevor das Projekt startet, denn sie nach einer strittigen Rechnung nachzurüsten ist langsamer und teurer. Erkennen Sie Abweichungen, solange Sie noch handeln können, denn ein an Tag zwei gemeldeter Mehraufwand ist eine Entscheidung und derselbe Mehraufwand in einer Monatsrechnung ein Verlust. Und lassen Sie nie eine einzelne Aktivitätskennzahl an die Stelle eines Ergebnisnachweises treten, denn eine Zahl, die sich steigern lässt, ohne dass etwas entsteht, wird irgendwann gesteigert, ohne dass etwas entsteht.

Nichts davon verlangt einen großen Prozessapparat. Es verlangt aufgeschlüsselte Aufgaben, ehrliche Schätzungen, ein kurzes regelmäßiges Review, einen vereinbarten Eskalationsschwellenwert und Nachweise, die Sie sich ansehen können. Die meisten mittelständischen Unternehmen bekommen das in wenigen Wochen aufgesetzt, und der Ertrag zeigt sich in besseren Entscheidungen und nicht in einer kleineren Rechnung.

Wenn Sie gerade die Zusammenarbeit nach Aufwand mit einem externen Team aufsetzen oder Ihr laufendes Projekt Rechnungen produziert, die Sie nicht interpretieren können, sprechen Sie uns an. Wir gehen gern mit Ihnen durch, wie sich Schätzung, Berichterstattung und Budgetkontrolle in Ihrem Projekt organisieren lassen - das Format der Aufschlüsselung, den Berichtsrhythmus, die Schwellenwerte und die Prognose - unabhängig davon, ob die Arbeit am Ende bei Webdelo landet. Es ist ein praktisches Gespräch über Ihren Lieferprozess, und in der Regel nehmen beide Seiten etwas Brauchbares daraus mit.