Individuelle Softwareentwicklung unterscheidet sich von anderen IT-Projekten dadurch, dass zu Beginn oft noch nicht jedes Detail feststeht – und genau darauf sollte die Beauftragung Rücksicht nehmen. Wer ein Festpreisangebot für ein Vorhaben verlangt, dessen Umfang sich erst im Projektverlauf klärt, bekommt entweder einen unrealistisch niedrigen Preis mit Nachträgen oder einen unrealistisch hohen mit eingepreistem Risiko. Wer dagegen ganz ohne Struktur nach Aufwand entwickeln lässt, verliert leicht den Überblick über Fortschritt und Kosten. Dieser Leitfaden beschreibt die Punkte, die Sie vor der Beauftragung klären sollten, damit beide Seiten von Anfang an dieselbe Erwartung haben.
Ziel und Umfang klären
Beschreiben Sie zunächst das eigentliche Ziel der Software, nicht nur eine Liste gewünschter Funktionen: Welches Problem soll gelöst werden, für wen, und woran würden Sie erkennen, dass die Software dieses Ziel erreicht? Unterscheiden Sie außerdem zwischen einem minimal funktionsfähigen ersten Umfang (oft als MVP bezeichnet) und dem vollständigen, langfristig gewünschten Funktionsumfang. Diese Unterscheidung hilft dabei, ein Projekt in überschaubare Etappen zu gliedern, statt von Anfang an ein sehr großes, schwer kalkulierbares Gesamtpaket zu beauftragen. Ein Anbieter, der das eigentliche Ziel kennt, kann außerdem eigene Vorschläge einbringen, wie es sich technisch einfacher oder günstiger erreichen lässt, als es eine reine Funktionsliste zulässt.
Festpreis vs. Aufwand
Bei individueller Softwareentwicklung gilt dieselbe Grundregel wie bei anderen IT-Projekten: Ein Festpreis passt zu einem klar abgegrenzten, gut beschriebenen Umfang, während eine Abrechnung nach Aufwand (Stunden- oder Tagessatz) besser zu Vorhaben passt, deren Umfang sich erst im Projektverlauf konkretisiert. Bei individueller Software ist Letzteres eher die Regel als die Ausnahme, weil sich Anforderungen häufig erst durch erste sichtbare Ergebnisse schärfen. Ein verbreitetes Zwischenmodell ist ein Festpreis pro Etappe oder Sprint bei insgesamt offenem Gesamtumfang – das begrenzt das Risiko auf einen überschaubaren Zeitraum, ohne den gesamten Projektumfang von Anfang an festzuschreiben. Welches Modell passt, hängt vom Reifegrad Ihrer Anforderungen ab; der Leitfaden zum Angebotsvergleich erklärt die gängigen Preismodelle im Detail.
Iterationen und Zusammenarbeit
Klären Sie, in welchem Rhythmus Sie Zwischenergebnisse sehen und Rückmeldung geben können – wöchentlich, nach jeder abgeschlossenen Funktion oder erst am Projektende. Regelmäßige, kurze Iterationen mit sichtbaren Zwischenständen verringern das Risiko, dass am Ende ein Ergebnis entsteht, das zwar der ursprünglichen Beschreibung entspricht, aber nicht mehr dem tatsächlichen Bedarf. Benennen Sie eine Person auf Ihrer Seite, die während des Projekts für fachliche Rückfragen zur Verfügung steht – ein Projekt ohne verfügbaren Ansprechpartner verzögert sich in der Praxis regelmäßig, weil der Anbieter auf Antworten warten muss, um weiterzuarbeiten.
Nutzungsrechte und Quellcode klären
Klären Sie, welche Nutzungsrechte Sie erhalten (ausschließlich oder einfach), ob der Quellcode übergeben wird und ab wann – etwa nach vollständiger Bezahlung. Dieser Leitfaden nennt den Punkt bewusst nur als offene Klärungsfrage, nicht als rechtliche Einschätzung, da die genaue Ausgestaltung vom Einzelfall und vom anwendbaren Recht abhängt. Fragen Sie außerdem, ob und in welchem Umfang externe Bibliotheken oder Komponenten Dritter verwendet werden und unter welchen Lizenzbedingungen diese stehen, da das die spätere Nutzung und Weiterentwicklung beeinflussen kann. Lassen Sie vertragliche Regelungen zu Nutzungsrechten, insbesondere bei geplanter Weiterentwicklung durch einen anderen Anbieter, im Zweifel von Ihrer Rechtsberatung oder einer spezialisierten Beratung prüfen, statt sich auf eine mündliche Zusage zu verlassen.
Qualitätssicherung und Tests
Klären Sie, wer während der Entwicklung für Tests verantwortlich ist und in welchem Umfang automatisierte Tests Teil der Lieferung sind. Ein Anbieter, der von Anfang an automatisierte Tests für zentrale Funktionen einplant, erleichtert spätere Änderungen erheblich, da sich Fehler durch neue Funktionen schneller auffinden lassen als bei rein manueller Prüfung. Fragen Sie außerdem, wie mit Fehlern umgegangen wird, die während einer laufenden Iteration auffallen – werden sie sofort behoben oder gesammelt und am Ende der Etappe bearbeitet? Ohne eine klare Vereinbarung zur Qualitätssicherung verschiebt sich das Testen häufig ganz ans Projektende, wo Korrekturen aufwendiger und teurer sind als während der laufenden Entwicklung.
Betrieb und Wartung nach der Einführung
Software endet nicht mit der Fertigstellung: Klären Sie, wer den laufenden Betrieb übernimmt – Hosting, Updates, Sicherheitskorrekturen – und ob dafür ein separater Wartungsvertrag vorgesehen ist. Klären Sie, wie lange und in welchem Umfang der Anbieter für Mängel einsteht und ob der Vertrag die gesetzliche Gewährleistung anpasst – das hängt auch davon ab, ob ein Werk- oder Dienstvertrag vorliegt. Ein Projekt, das die Zeit nach dem Go-live nicht mitplant, führt regelmäßig zu einer Lücke, in der niemand für auftretende Probleme zuständig ist.
Abnahme
Legen Sie vor Projektstart fest, anhand welcher Kriterien Sie die Software abnehmen – etwa definierte Testfälle, die erfolgreich durchlaufen werden müssen, oder eine gemeinsame Prüfung der zentralen Funktionen anhand des ursprünglich beschriebenen Ziels. Ohne solche Kriterien bleibt offen, wann ein Projekt wirklich abgeschlossen ist, und Meinungsverschiedenheiten über nötige Nacharbeiten sind vorprogrammiert. Der Leitfaden zur Leistungsbeschreibung zeigt, wie sich Ziel, Umfang und Abnahmekriterien bereits in der Anfrage festhalten lassen. Geht es dagegen um die Einführung einer bestehenden Standard- oder Business-Software statt einer Neuentwicklung, ist der Leitfaden zur ERP-Einführung der passendere Einstieg.
Checkliste
- Eigentliches Ziel beschrieben, nicht nur eine Funktionsliste
- MVP und langfristiger Gesamtumfang unterschieden
- Passendes Preismodell für den Reifegrad der Anforderungen gewählt
- Rhythmus für Iterationen und interner Ansprechpartner festgelegt
- Nutzungsrechte am Code und verwendete Drittkomponenten als Klärungspunkt benannt
- Zuständigkeit für Tests und Umgang mit gefundenen Fehlern vereinbart
- Betrieb, Wartung und Gewährleistung nach der Einführung geklärt
- Abnahmekriterien vor Projektstart festgelegt
Wenn Sie ein Individualsoftware-Projekt konkret angehen möchten, können Sie es auf Projektlotse beschreiben – mit Ziel, Umfang und den Rahmenbedingungen aus diesem Leitfaden. Geprüfte IT-Dienstleister aus Ihrer Region sehen die Anfrage und melden sich mit Rückfragen und Angeboten. Firmenname, genaue Adresse und Anhänge bleiben vertraulich, bis Sie sie gezielt für einzelne Dienstleister freigeben. Die Nutzung ist in der aktuellen Startphase kostenlos.