Warum Projekte mit Software-Agenturen enttäuschen: ein evidenzbasierter Leitfaden

Verfehlte Erwartungen, fehlerhafte Releases, verspätete Lieferungen und strittige Rechnungen können bei ausgelagerter Softwarearbeit auftreten. Sie beweisen nicht, dass Agenturen als Kategorie schlecht sind. Eine sinnvolle Prüfung trennt Nachweise über ein konkretes Projekt und einen Anbieter von Annahmen über das Liefermodell.

Ergebnisse hängen von Problem, Anbieterfähigkeit, Kundenentscheidungen, Vertrag, Abhängigkeiten, Nachweisen und Betriebsumgebung ab. Käufer und Anbieter können Risiken erzeugen oder senken. Dieser Leitfaden macht daraus Fragen für Auswahl und Lieferung.

Nutze Beschränkungen als Planungsgespräch, nicht als Gesetz

Zeit, Kosten, Umfang und Qualität sind nützliche Planungsdimensionen, doch das bekannte Dreieck oder Viereck ist eine Heuristik, keine Vorhersageformel. Eine Änderung kann mehrere Dimensionen betreffen; Richtung und Größe hängen von Architektur, Reihenfolge, Fähigkeiten, Automatisierung, Abhängigkeiten und Risiko ab.

Dokumentiere damit Abwägungen: Welcher Termin ist fest? Welche Ergebnisse sind unverzichtbar? Welche Qualitätsmerkmale sind risikokritisch? Welche Budgetspanne und Unsicherheit sind freigegeben? Welche Annahme würde den Plan ändern? Mehr Geld verbessert Qualität nicht automatisch, und mehr Personen holen einen Zeitplan nicht automatisch auf.

Definiere Ergebnisse und Abnahmenachweise vor dem Anbietervergleich

Beschreibe Nutzer- oder Geschäftsergebnis, Ausgangswert, betroffene Personen, Einschränkungen und Verantwortung. Definiere dann die Abnahme jedes Schritts, etwa funktionierende Journeys, automatisierte Tests, Sicherheitsbefunde, Barrierefreiheit, Leistung, abgestimmte Daten, Runbooks und Stakeholder-Freigaben.

Das aktuelle britische Sourcing Playbook empfiehlt für öffentliche Beschaffung ergebnisorientierte Spezifikationen, frühe Marktbeteiligung, Sollkostenmodelle, Tests, Piloten, Risikoverteilung und Leistungsmessung. Es ist keine universelle Vertragsvorlage, bietet aber nützliche Fragen.

Mache Fortschritt in kleinen Schritten prüfbar

Ein Statusbericht ist kein Nachweis nutzbarer Software. Vereinbare einen risikogerechten Rhythmus, der funktionierende Inkremente, Entscheidungen, blockierte Abhängigkeiten, Prognoseänderungen, Fehler und Abnahmen zeigt.

Der US-Rechnungshof beschreibt Agile als inkrementelle Entwicklung mit laufender Prüfung von Funktion, Qualität und Kundenzufriedenheit. Sein Agile Assessment Guide richtet sich an Behörden, stützt aber das Prinzip häufiger Reviews und Kundenfeedbacks. Inkremente reduzieren manche Risiken, garantieren aber weder Termin noch Budget oder Erfolg.

Behandle Qualität als Risikoentscheidung

Mehr Tests erzeugen keine universelle exponentielle Kostenkurve, und weniger Fehler lassen sich nicht allein aus Stunden ableiten. Wirksamkeit hängt von Anforderungen, Design, Testauswahl, Umgebung, Automatisierung, Reviewqualität, Bedrohung und Betriebsfeedback ab.

Definiere relevante Eigenschaften: Korrektheit, Sicherheit, Datenschutz, Barrierefreiheit, Leistung, Resilienz, Wartbarkeit und Wiederherstellung. Ein internes Hilfstool braucht andere Nachweise als Software mit Sicherheits-, Finanz-, Identitäts- oder Rechtsfolgen. Behandle Luftfahrt, Web3 oder andere Branchen nicht als einheitliche Risikoklasse.

NISTs Secure Software Development Framework ist ergebnisorientiert und soll an Geschäftszweck, Risikotoleranz und Ressourcen angepasst werden. Es empfiehlt Risiko, Kosten, Machbarkeit und Anwendbarkeit abzuwägen, statt eine Checkliste unverändert zu übernehmen.

Schätze Unsicherheit, statt sie zu verstecken

Eine Schätzung sollte Umfang, Annahmen, Ausschlüsse, Abhängigkeiten, Methode, Konfidenz und Aktualisierungsbedingungen nennen. Trenne geschätzte Arbeit, identifizierte Risikoexposition und Managemententscheidungen über zusätzliche Mittel. Nicht jedes Projekt braucht genau drei Budgettöpfe, und Reserven senken nicht das technische Risiko selbst.

Das Cost Estimating Handbook der NASA ist für NASA-Programme gedacht, nicht für normale Agenturprojekte. Es ist dennoch eine belastbare Referenz für Schätzgrundlage, Risiko, Unsicherheit, Spannen und Aktualisierung. Passe die Methode an, statt Raumfahrt-Governance zu kopieren.

Ordne Risiken der Partei mit der besten Steuerungsmöglichkeit zu

Erstelle vor der Preisbildung eine Risikomatrix. Erfasse Ursache, Folge, Frühindikator, Verantwortung, Minderung, Restrisiko, Entscheidungsrechte und kommerzielle Behandlung. Manche Risiken liegen beim Anbieter, manche beim Käufer, manche gemeinsam. Vertragliche Übertragung schafft keine praktische Kontrolle.

Die aktuelle britische Leitlinie Risk Allocation and Pricing Approaches empfiehlt, Risiken der Partei mit der besten Steuerungsmöglichkeit zuzuordnen und Preise nach Inputs, Outputs und Ergebnissen zu unterscheiden. Leistungskennzahlen sollen objektiv sein und nur beeinflussbare Ergebnisse umfassen. Für das konkrete Mandat gilt lokales Beschaffungs- und Vertragsrecht.

Wähle Preise passend zu Unsicherheit und Kontrolle

Zeitbasierte, fixe, Meilenstein-, gedeckelte und ergebnisbezogene Modelle verteilen Unsicherheit unterschiedlich. Keines ist automatisch ehrlich oder effizient. Festpreis kann bei stabil spezifizierbaren Ergebnissen passen. Zeitbasierte Arbeit kann Discovery oder veränderlichen Umfang tragen, wenn Ausgaben, Prioritäten und Stoppregeln sichtbar bleiben. Ergebnispreise verlangen messbare Resultate und faire Berücksichtigung fremder Abhängigkeiten.

Vergleiche Angebote auf gleicher Grundlage. Frage nach Einschlüssen, Ausschlüssen, Annahmen, Änderungen, Gewährleistung, Support, Lizenzen und Übergabe. Modelliere interne Arbeit, Drittkosten, Cloud, Sicherheitsprüfung, Datenmigration, Betrieb und Exit, nicht nur die Anbieterrechnung.

Gestalte Change Control nützlich statt strafend

Software-Discovery verändert Wissen. Ein guter Änderungsnachweis nennt Auslöser, betroffene Anforderung, Optionen, Folgen für Nachweise, Kosten- und Terminspanne, Entscheidungsverantwortung und Freigabe. Er schützt die Baseline und erlaubt bewusste Änderung.

Klassifiziere nicht jede Klarstellung als kostenpflichtige Erweiterung und nicht jeden neuen Wunsch als enthalten. Vereinbare die Trennung von Fehler, fehlender Abnahme, Rechtsänderung, Abhängigkeitsausfall und neuem Produktumfang. Prüfe kumulierte Änderungen gegen den Business Case.

Fordere Betriebsverantwortung und Exit-Pfad

Lieferung ist unvollständig, wenn niemand Betrieb, Sicherheit, Support und Änderung verantwortet. Definiere Repositories, Zugriffe, Umgebungen, Deployment, Beobachtbarkeit, Vorfälle, Backups, Wiederherstellung, Datenexport, Dokumentation, Lizenzen, Zugangsdaten, Lieferantenabhängigkeiten und Wissenstransfer.

Lege Befugnisse fest: Wer nimmt ab, priorisiert, genehmigt Produktionszugriff, akzeptiert Restrisiko und stoppt Releases? Ein Berater, Product Owner, Engineering Lead oder Fractional Executive kann helfen, aber kein Titel richtet Anreize automatisch aus. Vertrags- und Beschäftigungsklassifikation folgen tatsächlicher Zusammenarbeit und Rechtsraum, nicht Marketingbezeichnungen.

Was sollte ein Käufer prüfen?

Warnsignale brauchen Kontext

• Präzise Kosten oder Termine ohne Annahmen, Discovery oder Konfidenz.
• Subjektive Zufriedenheit statt beobachtbarer Abnahmekriterien.
• Keine funktionierenden Inkremente, Fehler oder Prognoseänderungen.
• Risiken bei einer Partei, die sie nicht kontrollieren kann.
• Materielle Sicherheit, Datenschutz, Barrierefreiheit, Datenmigration, Betrieb oder Exit fehlen.
• Der Käufer hat keine befugte Verantwortung für Priorität, Abnahme, Abhängigkeiten und Entscheidungen.

Das sind Due-Diligence-Fragen, kein Beweis ungeeigneter Anbieter. Fordere Nachweise an und bewerte die Antwort nach Projektrisiko.

Wie sollte Wavects Modell bewertet werden?

Bewerte Wavect gleich. Unsere Leistungen für individuelle Softwareentwicklung und Fractional CTO beschreiben unterschiedliche Hilfe, beweisen aber weder Passung, Ergebnis, Unabhängigkeit noch Rechtsklassifikation. Fordere ein Angebot mit Umfang, Annahmen, Team, Befugnissen, Preis, Nachweisen, Risiken, Abhängigkeiten, Übergabe und Exit.

Ausgewählte Fallstudien und Referenzen sind Nachweise ausgewählter Arbeit, kein vollständiger Erfolgsdatensatz und keine Garantie. Prüfe aktuelle Referenzen, relevante Erfahrung, Konflikte, Verfügbarkeit, Sicherheitspraxis und ausführende Personen.