7 Fragen, die Sie sich vor jedem Softwareprojekt stellen sollten

In den letzten 13 Jahren habe ich Software gebaut, gerettet und manchmal beerdigt. Für Konzerne, für Start-ups, und seit BespokeCode vor allem für mittelständische Unternehmen aus dem Münchner Raum.

Eines ist in fast jedem Projekt gleich: Die wirklich teuren Fehler entstehen nicht im Code. Sie entstehen vorher, in Entscheidungen, die ein halbes Jahr vor der ersten Zeile Programmierung getroffen werden. Manchmal werden sie gar nicht bewusst getroffen, sondern einfach übersehen.

Wenn Sie als Geschäftsführer über ein Softwareprojekt nachdenken (egal ob neue Website, individuelle Anwendung oder die Automatisierung eines Prozesses), gibt es sieben Fragen, die Sie sich stellen sollten, bevor Sie das erste Gespräch mit einem Dienstleister führen. Sie ersetzen keine Beratung. Aber sie sorgen dafür, dass Sie die Beratung bekommen, die Sie wirklich brauchen.

1. Welches Geschäftsproblem soll die Software lösen, und wie messen wir Erfolg?

Das klingt banal, ist es aber nicht.

Ich habe schon Anfragen bekommen, die mit "Wir brauchen eine App" oder "Wir wollen ein neues CRM" anfingen. Wenn ich dann gefragt habe, was die App oder das CRM eigentlich leisten soll, kam oft eine lange Liste mit Features, kein klares Problem, dass gelöst werden soll.

Software ist ein Werkzeug, kein Ziel, dass es zu erreichen gilt. Bevor Sie über Technik nachdenken, sollten Sie einen Satz formulieren können, der ungefähr so klingt: "Heute kostet uns Problem X monatlich Y Stunden oder Z Euro, und das wollen wir mit der neuen Software auf N reduzieren." Wenn dieser Satz nicht steht, wird das Projekt entweder ausufern, weil niemand weiß, wann es fertig ist, oder es wird etwas gebaut, das technisch funktioniert, aber das eigentliche Problem nicht löst.

Konkret: Was würden Sie als Geschäftsführer in sechs Monaten als Erfolg beschreiben? Welche Zahl muss sich bewegen? Ein kürzerer Auftragsdurchlauf, weniger manuelle Fehler in der Abrechnung, mehr qualifizierte Anfragen pro Monat. Diese Antwort ist wichtiger als jede Anforderungsliste.

2. Bauen oder kaufen: Gibt es Standardsoftware, die 80 Prozent abdeckt, und sind das die richtigen 80 Prozent?

Ich verdiene mein Geld damit, Software zu bauen. Trotzdem ist meine erste Frage in fast jedem Erstgespräch: Haben Sie geprüft, ob es eine Standardlösung gibt?

Das ist nicht nur Ehrlichkeit, sondern Erfahrung. Individualsoftware lohnt sich, wenn ein Prozess wirklich einzigartig ist oder zu einem klaren Wettbewerbsvorteil führt. Sie lohnt sich nicht, wenn eine etablierte Lösung das abdeckt, was Sie brauchen, und die Lücken sich mit etwas Prozessanpassung schließen lassen.

Die 80/20-Faustregel ist dabei nützlich, jedoch passiert hier häufig ein Denkfehler. Nicht jede 80-Prozent-Abdeckung hat den gleichen Wert. Wenn eine Standardlösung die wichtigen 80 Prozent abdeckt (Buchhaltung, Stammdaten, Standardberichte) und die fehlenden 20 Prozent reine Komfortfunktionen sind, ist das ein guter Deal. Wenn aber genau in den fehlenden 20 Prozent das steckt, was Ihr Geschäft eigentlich ausmacht (Ihre Kalkulationslogik, Ihr Konfigurator, Ihre Schnittstelle zur Produktion), dann erfüllt die Software zwar auf dem Papier 80 Prozent, löst jedoch trotzdem das eigentliche Problem nicht.

Lieber 60 Prozent, die genau die richtigen 60 Prozent sind, als 80 Prozent, in denen der Kern Ihres Geschäfts fehlt.

Ein Beispiel aus meiner Praxis: Eine Agentur aus dem Münchner Umland wollte zunächst ein komplett eigenes Projektmanagement-System. Nach einem Tag Analyse war klar: Was sie wirklich brauchte, war eine schlanke Eigenentwicklung, die zwischen ihrem bestehenden Projekttool und ihrer Zeiterfassung vermittelte. Aufwand und Risiko: ein Bruchteil eines vollen Eigenbau-Projekts, und genau in den 20 Prozent, in denen ihr Geschäft entstand.

Zwei Entwicklungen verschieben diese Abwägung gerade fundamental: KI senkt die Kosten von Eigenentwicklung deutlich, und das Thema Datensouveränität (Stichwort US Cloud Act bei amerikanischen Anbietern) wird für KMU zunehmend zur Geschäftsführer-Entscheidung. Beides macht "bauen" heute öfter zur richtigen Antwort als noch vor wenigen Jahren. (Dazu folgt ein eigener Artikel.)

3. Was kostet das Nicht-Handeln?

Software wirkt teuer, solange man nur auf die Rechnung schaut, sie wirkt jedoch günstig, sobald man die Alternative ehrlich durchrechnet.

Viele KMU haben sich an ihre eigenen Workarounds gewöhnt: die Excel-Tabelle, die jeden Montag drei Stunden Pflege braucht. Den manuellen Übertrag zwischen zwei Systemen, der pro Woche zwei Fehler produziert. Die E-Mail-Kette mit 14 Beteiligten, in der regelmäßig etwas durchrutscht.

Bevor Sie ein Softwareprojekt ablehnen, weil es 20.000 oder 50.000 Euro kostet, rechnen Sie aus, was der aktuelle Zustand kostet. Stundenlohn der involvierten Mitarbeiter, Fehlerkosten, verlorene Anfragen, Zeit, die der Inhaber selbst in operative Reparaturen steckt statt ins Geschäft.

Oft sieht die Rechnung in etwa so aus: 8 Stunden manuelle Arbeit pro Woche, mal 50 Euro durchschnittliche Vollkosten, mal 48 Wochen sind rund 19.000 Euro pro Jahr. Eine einmalige Investition von 25.000 Euro, die diese Stunden eliminiert, ist nach 16 Monaten amortisiert, und läuft danach jahrelang ohne nennenswerte Folgekosten weiter.

Das heißt nicht, dass sich jede Investition rechnet. Es heißt, dass die Frage "Was kostet uns das?" nur ehrlich beantwortet werden kann, wenn man "Was kostet es uns das nicht zu tun?" daneben stellt.

4. Wer im Unternehmen muss mitziehen, damit die Software überhaupt genutzt wird?

Die unbeliebteste Wahrheit in der Softwareentwicklung: Technik ist selten der Grund, warum Projekte scheitern, es sind die Menschen die sie Nutzen sollen.

Ich habe Projekte gesehen, die technisch sauber abgeliefert wurden und trotzdem nie produktiv gingen, weil das Team sie nicht akzeptiert hat. Weil der Vertrieb sein altes Excel weiter nutzt. Weil der Lagerleiter den neuen Scan-Prozess sabotiert, weil ihn niemand gefragt hat. Weil die Geschäftsführung das Projekt angestoßen hat, dann aber im Tagesgeschäft verschwand und das Team allein ließ.

Bevor Sie ein Projekt starten, sollten Sie ehrlich beantworten: Wer ist die wichtigste Person für die spätere Nutzung, und steht diese Person hinter dem Projekt? Wer wird durch die Software in seinem bisherigen Arbeitsmodus eingeschränkt und wie holen wir diese Person ab? Wer hat die Autorität, Konflikte zu entscheiden, wenn der Vertrieb etwas anderes will als die Produktion?

Wenn die Antwort lautet "Das klären wir später", ist das ein Warnsignal. Software ohne klare interne Verantwortung scheitert nicht an der Technik, sondern sie scheitert an der ersten Sitzung, in der jemand sagt: "So haben wir das aber bisher nicht gemacht."

5. Wie sieht der erste nutzbare Stand aus, und wann ist er produktiv?

Wenn ein Dienstleister Ihnen erzählt, das Projekt sei in 9 Monaten fertig und Sie sehen vorher nichts Nutzbares, dann Misstrauen Sie der Aussage.

Gute Softwareprojekte werden in Schritten geliefert, nicht in einem großen Wurf am Ende. Nicht weil das modisch ist, sondern weil drei Dinge dadurch besser werden. Sie sehen früh, ob die Richtung stimmt. Sie können während der Entwicklung lernen und Anforderungen anpassen. Und das Risiko ist gedeckelt, falls etwas schiefläuft.

Die Frage, die Sie stellen sollten, lautet: Was ist der kleinste Stand, der für mein Unternehmen schon einen echten Mehrwert bringt, auch wenn er noch nicht alles kann? Bei einem CRM ist das vielleicht "Kontakte und Aktivitäten erfassen, nichts weiter". Bei einer Prozessautomatisierung "den einen Hauptprozess automatisieren, die Sonderfälle bleiben vorerst manuell". Bei einer Website "drei Kernseiten live, der Rest folgt".

Wenn Sie diese erste Version in 6 bis 10 Wochen live haben können, sind Sie auf einem guten Weg. Wenn der Dienstleister Ihnen erzählt, vorher gehe gar nichts, fragen Sie nach. Manchmal stimmt das, oft ist es aber ein Hinweis darauf, dass das Projekt zu groß geschnitten wurde.

6. Was passiert, wenn der Dienstleister morgen ausfällt?

Diese Frage stelle ich mir selbst, bevor ich sie meinen Kunden stelle. Ich bin Solo-Anbieter, und meine Kunden vertrauen mir teilweise geschäftskritische Anwendungen an. Das funktioniert nur, wenn ich von Anfang an dafür sorge, dass sie nicht von mir abhängig sind.

Konkret heißt das: Der Quellcode liegt in einem Repository, auf das Sie Zugriff haben, nicht nur ich. Die Dokumentation ist so geschrieben, dass ein anderer Entwickler einsteigen kann. Das Hosting läuft auf Infrastruktur, die Sie kennen, mit Zugangsdaten, die Sie besitzen. Verwendete Technologien sind verbreitet genug, dass es einen Markt für Nachfolger gibt.

Egal ob Sie mit einer Agentur, einem Freelancer oder einem Solo-Anbieter wie mir arbeiten, Fragen Sie konkret nach. Wem gehört der Code? Wo liegt er? Wer hat die Zugänge? Was passiert mit der Dokumentation? Wie sähe ein Wechsel zu einem anderen Dienstleister aus, falls es nötig würde?

Ein guter Dienstleister wird diese Fragen nicht als Misstrauen verstehen, sondern als Professionalität. Wer ausweicht, hat oft etwas zu verbergen, und sei es nur die Tatsache, dass diese Themen bisher nicht durchdacht wurden.

7. Wie wachsen wir mit der Software, ohne uns in zwei Jahren neu zu erfinden?

Die meisten Softwareprojekte werden für den Zustand gebaut, in dem das Unternehmen heute ist, das ist zwar verständlich, aber langfristig gefährlich.

Ich frage in jedem Erstgespräch, wo möchten Sie in zwei bis drei Jahren stehen? Nicht im Detail, aber grob. Doppelt so viele Mitarbeiter? Eine zweite Niederlassung? Ein neues Produkt? Internationalisierung? Diese Antworten beeinflussen nicht jede technische Entscheidung, aber sie beeinflussen die wichtigen: Datenstruktur, Mehrsprachigkeit, Mandantenfähigkeit, Rollen- und Rechtekonzept.

Was Sie nicht tun sollten ist, alles auf Verdacht überdimensionieren, denn Software die für Funktionen vorbereitet wird, die nie kommen, ist teurer und langsamer als nötig.

Was Sie schon tun sollten, die zwei oder drei wahrscheinlichsten Wachstumsszenarien mit dem Dienstleister durchsprechen, bevor die Architektur steht. Ein erfahrener Entwickler kann an wenigen Stellen Entscheidungen treffen, die spätere Erweiterungen einfach machen, ohne heute nennenswert mehr zu kosten. Diese wenigen Stellen zu kennen, ist der Unterschied zwischen "lebt zehn Jahre" und "wird in zwei Jahren neu gebaut".

Diese Fragen ersetzen keine Beratung, sie machen sie besser.

Wenn Sie diese sieben Fragen vor dem ersten Gespräch mit einem Anbieter durchgehen, wird zweierlei passieren. Sie werden bessere Gespräche führen, weil Sie konkretere Antworten bekommen und Sie werden schneller erkennen, welcher Anbieter wirklich an Ihrem Erfolg interessiert ist und welcher nur ein Angebot platzieren will.

Mein Versprechen als Solo-Anbieter ist genau das: ehrliche Beratung vor dem Auftrag, auch wenn am Ende herauskommt, dass Sie gar keine individuelle Software brauchen. Pragmatische Umsetzung, wenn Sie eine brauchen. Und Software, die Ihrem Unternehmen gehört, nicht mir.

Wenn Sie diese Fragen für Ihr nächstes Projekt strukturiert durchgehen möchten: Ich arbeite gerade an einer kostenlosen Checkliste als PDF, die Sie als Vorbereitung für interne Gespräche und Termine mit Anbietern nutzen können. (Bald verfügbar.)

Wenn Sie konkrete Fragen zu einem Projekt haben: Buchen Sie ein unverbindliches 20-Minuten-Erstgespräch. Kein Verkaufstermin, sondern eine ehrliche Einschätzung, ob und wie sich Ihr Vorhaben sinnvoll umsetzen lässt.