Softwareprojekt starten: Was vor dem ersten Sprint geklärt sein muss

Problem

Viele Softwareprojekte scheitern nicht daran, dass zu wenig gearbeitet wird. Sie scheitern daran, dass zu früh in Umsetzung gewechselt wird, obwohl Ziel, Scope, Verantwortung, Nutzerbedarf und technische Rahmenbedingungen noch nicht zusammenpassen. Dann startet zwar ein Sprint, aber das Projekt hat noch keinen belastbaren Modus.

Das zeigt sich später als Scope Creep, Budgetdruck, technische Schulden oder als dauernde Nachverhandlung: Was war eigentlich gemeint? Wer entscheidet? Welche Nutzergruppe zählt zuerst? Welche Bestandssoftware darf nicht gefährdet werden? Solche Fragen gehören vor den ersten Sprint, nicht erst in seine Mitte.

Ein Softwareprojekt beginnt deshalb nicht mit der ersten Zeile Code. Es beginnt mit einer strukturierten Klärung, die aus einer Idee ein Projekt macht. Genau dort liegen die wichtigsten Schritte.

Einordnung: Startklar ist nicht gleich umsetzungsbereit

Eine Projektidee kann sinnvoll sein und trotzdem noch nicht umsetzungsbereit. Das ist kein Widerspruch. Gerade bei internen Tools, Kundenportalen, Modernisierung oder Bestandsübernahme ist die erste Aufgabe nicht, möglichst schnell ein Backlog zu füllen. Die erste Aufgabe ist zu verstehen, ob das Vorhaben schon genug Klarheit für Umsetzung hat.

Ein Projekt ist eher startklar, wenn diese Punkte greifbar sind:

• ein konkretes Zielbild und ein messbarer erster Nutzen
• ein begrenzter Scope für den ersten Release
• benannte fachliche Verantwortung, meist in Form eines Product Owners
• priorisierte Anforderungen für die ersten zwei bis drei Sprints
• eine erste Sicht auf Architektur, Schnittstellen, Daten und Betrieb
• ein abgestimmtes Arbeitsmodell mit Review-, Entscheidungs- und Kommunikationsrhythmus

Fehlen mehrere dieser Punkte, ist eine Discovery-Phase oft der bessere nächste Schritt. Sie muss nicht groß sein. Für kleinere Vorhaben reichen manchmal wenige Workshops. Bei Bestandssoftware, Systemmodernisierung oder mehreren Stakeholdern sind zwei bis vier Wochen Discovery häufig realistischer, weil fachliche und technische Risiken gemeinsam sichtbar werden müssen.

Ausgangslage: Warum, für wen und auf welcher Basis?

Bevor ein Softwareprojekt startet, sollte die Ausgangslage in einfachen Worten beschreibbar sein. Warum jetzt? Für wen wird gebaut? Und auf welcher technischen oder organisatorischen Basis beginnt das Projekt?

Bei einem neuen internen Tool kann der Anlass zum Beispiel sein, dass Excel, E-Mail und manuelle Übergaben zu viele Fehler erzeugen. Bei einem Kundenportal kann es darum gehen, wiederkehrende Anfragen in einen Self-Service-Prozess zu bringen. Bei einem Bestandssystem kann der eigentliche Auslöser sein, dass Releases riskant geworden sind oder Wissen nur noch bei einzelnen Personen liegt.

Hilfreiche Fragen für den Start sind:

• Welcher Prozess soll nach dem Projekt spürbar besser funktionieren?
• Welche Nutzergruppen sind betroffen: interne Teams, Kunden, Partner oder Admins?
• Welche bestehenden Systeme, Datenbanken, APIs oder Oberflächen müssen eingebunden werden?
• Wo entsteht heute der größte Aufwand, das größte Risiko oder die meiste Unsicherheit?
• Was darf während der Umsetzung auf keinen Fall ausfallen?

Diese Einordnung entscheidet auch über den richtigen Einstieg. Ein neues Tool führt häufig zu Interne Tools entwickeln lassen . Ein laufendes, schwer wartbares System passt eher zu bestehende Software übernehmen und weiterentwickeln . Wenn technische Schulden, fragile Schnittstellen oder Legacy-Risiken im Vordergrund stehen, ist Systemmodernisierung der passendere Rahmen.

Zielbild und Scope: Was gehört in dieses Projekt?

Ein Zielbild gibt Richtung. Scope entscheidet, was davon jetzt wirklich bearbeitet wird. Beides muss getrennt werden, weil sonst aus einer sinnvollen Vision sehr schnell ein zu großer erster Release wird.

Ein Zielbild kann lauten: “Alle manuellen Onboarding-Prozesse sollen bis 2027 digital unterstützt werden.” Der erste Scope kann trotzdem viel enger sein: nur Österreich, nur B2B-Kunden, nur Standardprodukte, nur die ersten drei Prozessschritte. Diese Begrenzung ist kein Verlust. Sie macht das Projekt lieferbar.

Gute Scope-Arbeit beantwortet mindestens drei Fragen:

• Welche Wirkung muss die erste Etappe unbedingt erzeugen?
• Welche Funktionen sind dafür notwendig, welche nur angenehm?
• Welche Abhängigkeiten würden den ersten Schritt unnötig riskant machen?

Genau hier schließt die Vertiefung Warum Scope vor der Featureliste kommt an. Eine Featureliste zeigt, was wichtig sein könnte. Scope entscheidet, was zusammen in eine tragfähige erste Etappe gehört.

Anforderungen: Von groben Zielen zu User Stories

Ein Softwareprojekt braucht keine 80-seitige Spezifikation, bevor es starten darf. Es braucht aber genug Struktur, damit Anforderungen nicht nur als Wünsche im Raum stehen. User Stories sind dafür oft ein guter Rahmen, weil sie Rolle, Funktion und Nutzen verbinden.

Eine brauchbare User Story folgt meistens diesem Muster:

Als Sachbearbeiter möchte ich Anträge direkt aus Outlook übernehmen, damit doppelte Erfassung entfällt.

Daraus wird erst dann eine umsetzbare Anforderung, wenn Akzeptanzkriterien, Business Value, Abhängigkeiten und offene Fragen sichtbar sind. Für den Start reicht es nicht, alle Anforderungen vollständig zu kennen. Sinnvoll ist ein grobes Backlog für drei bis sechs Monate und detaillierte Stories für die ersten zwei bis drei Sprints.

Wichtig ist die Validierung: Stimmen die Anforderungen mit dem tatsächlichen Bedarf der Nutzer überein? Wurde mit den Menschen gesprochen, die später im System arbeiten? Sind fachliche Sonderfälle verstanden oder nur vermutet? Ohne diese Prüfung entsteht leicht Software, die formal umgesetzt wurde, aber am Alltag vorbeigeht.

Priorisierung und Roadmap: Welche Funktionen kommen wann?

Nach Zielbild und Anforderungen braucht das Projekt eine erste Reihenfolge. Eine Roadmap ist dabei kein starrer Plan für jedes Detail. Sie zeigt, welche Etappen zusammengehören und wo Entscheidungen später mit besserem Wissen neu getroffen werden.

Eine einfache Priorisierung reicht oft aus:

Bei Modernisierung gehören auch technische Meilensteine in die Roadmap: eine API entkoppeln, Tests für kritische Logik ergänzen, einen alten SOAP-Service ersetzen, ein Frontend schrittweise ablösen oder Release-Prozesse stabilisieren. Bei laufenden Systemen ist genau diese Mischung aus Fachlichkeit und Technik entscheidend.

Mehr dazu passt zu warum Priorisierung und Release-Sicherheit zusammengehören .

Arbeitsmodell: Wie wird konkret zusammengearbeitet?

Vor dem ersten Sprint sollte klar sein, wie Entscheidungen getroffen und Ergebnisse überprüft werden. Scrum, Kanban oder ein hybrides Modell sind nur dann hilfreich, wenn sie zur Projektsituation passen.

Ein typisches Setup kann so aussehen:

• ein Kickoff von einigen Stunden, um Ziele, Rollen, Risiken und erste Etappe zusammenzuführen
• zweiwöchige Sprints mit Review und Priorisierung
• ein benannter Product Owner auf Kundenseite
• ein technischer Lead für Architektur, Schnittstellen und Umsetzungsrisiken
• kurze regelmäßige Statuspunkte statt langer unklarer Abstimmungen

Bei laufendem Betrieb ist häufig ein hybrides Vorgehen sinnvoll. Kanban hilft bei Stabilisierung, Support und kleineren Eingriffen. Scrum oder sprintähnliche Etappen helfen bei neuen Features, Portalen oder Modernisierungsschritten. Die Seite Arbeitsweise beschreibt, wie aus dieser frühen Klärung ein tragfähiger Umsetzungsmodus wird.

Technische Risiken: Architektur, Schnittstellen und Betrieb

Viele Projekte geraten nicht wegen falscher Features unter Druck, sondern wegen unterschätzter technischer Rahmenbedingungen. Deshalb müssen Architektur, Schnittstellen, Daten, Sicherheit und Betrieb früh genug sichtbar werden.

Vor dem Start sollten mindestens diese Punkte geklärt sein:

• Hosting und Betriebsmodell: On-Premises, Cloud, Azure, bestehende Infrastruktur
• Sicherheitsanforderungen: Rollen, Berechtigungen, Logging, DSGVO, Zugriffskonzepte
• Daten und Schnittstellen: Datenqualität, Imports, Exports, APIs, ERP oder CRM
• technische Schulden: veraltete Frameworks, fehlende Tests, direkte Datenbankzugriffe
• Release-Risiken: Deployment, Rollback, Staging, Monitoring, Verantwortlichkeiten

Gerade bei gewachsenen .NET-Systemen, älteren Webanwendungen oder internen Tools ist ein begrenzter technischer Audit vor der Umsetzung oft sinnvoll. Drei bis fünf Tage reichen manchmal, um die wichtigsten Risiken sichtbar zu machen. Danach lässt sich verlässlicher entscheiden, ob Stabilisierung, API-Schnitt, neues Frontend oder ein kleiner erster Release der richtige Einstieg ist.

Empfehlung: Erst Discovery, wenn die Projektbasis noch unscharf ist

Discovery ist kein Extra, das man nur macht, wenn noch Zeit übrig ist. Sie ist die Phase, in der Idee, Nutzerbedarf, Scope, technische Realität und wirtschaftlicher Rahmen zusammengebracht werden. Ohne diese Basis erzeugt agile Entwicklung nur schneller sichtbare Unklarheit.

Ein Projekt kann meist direkt in Umsetzung gehen, wenn Ziel, Scope, erste Stories, Rollen, Roadmap und technische Risiken ausreichend klar sind. Discovery ist sinnvoll, wenn der Business Case unklar ist, Stakeholder unterschiedliche Ziele verfolgen, ein Legacy-System kaum dokumentiert ist oder intern niemand die fachliche Verantwortung sauber bündeln kann.

Das Ergebnis einer guten Discovery muss nicht groß sein. Oft reicht ein kompakter Projekt-One-Pager: Ziel, Nutzergruppen, Systeme, Risiken, erster Release, offene Fragen, Arbeitsmodell und grobe Roadmap. Wichtig ist, dass alle Beteiligten dieselbe erste Etappe sehen.

Nächster Schritt

Wenn ein Softwareprojekt im Raum steht, aber Ziel, Scope oder technische Basis noch unscharf sind, ist der beste nächste Schritt eine kurze Einordnung. Für konkrete Vorhaben führt Kontakt direkt weiter.

Wenn Sie vorher selbst sortieren möchten, helfen diese Anschlüsse:

• Arbeitsweise für den Projektmodus von Anfrage bis Go-live
• Warum Scope vor der Featureliste kommt für die Begrenzung der ersten Etappe
• Interne Tools entwickeln lassen für neue Tools, Admin-Bereiche und Kundenportale
• Bestehende Software übernehmen für laufende Systeme, die stabilisiert und weiterentwickelt werden müssen
• Systemmodernisierung für gewachsene .NET- und Web-Systeme mit technischem Risiko

Häufige Fragen

Wie lange sollte die Vorbereitung vor dem ersten Sprint dauern?

Für klar umrissene Vorhaben reichen oft ein bis zwei Wochen. Bei Bestandssoftware, Modernisierung, mehreren Stakeholdern oder unklarer Datenlage sind zwei bis vier Wochen realistischer. Die Vorbereitung ist keine Pause vor der Arbeit, sondern ein Teil der Projektarbeit.

Wie detailliert müssen Anforderungen vor dem Start sein?

Nicht jede Anforderung muss im Detail beschrieben sein. Sinnvoll ist ein grobes Backlog für drei bis sechs Monate und eine detaillierte Sicht auf die ersten zwei bis drei Sprints. Dazu gehören Akzeptanzkriterien, Priorität, fachlicher Nutzen und bekannte Abhängigkeiten.

Was kostet ein professioneller Projektstart?

Das hängt stark von Umfang, Bestand und Risiko ab. Ein kurzer Discovery-Workshop ist etwas anderes als eine mehrwöchige Analyse eines gewachsenen Systems. Entscheidend ist weniger ein pauschaler Betrag als die Frage, ob danach Scope, Risiken und erste Etappe belastbar genug sind.

Kann man ein laufendes, chaotisches Softwareprojekt stabilisieren?

Ja, aber selten durch noch mehr Geschwindigkeit. Ein Projekt-Reset braucht einen ehrlichen Blick auf Code, Architektur, Backlog, Rollen und Zusammenarbeit. Oft ist zuerst Stabilisierung nötig, bevor neue Features wieder sinnvoll geplant werden.

Welche Rolle spielt das interne Team beim Projektstart?

Das interne Team ist entscheidend. Es bringt Prozesswissen, Systemzugänge, Nutzerperspektive und Entscheidungskontext ein. Ein externer Partner kann Struktur, technische Führung und Umsetzung ergänzen, ersetzt aber keine interne Verantwortung.

Fazit

Ein erfolgreiches Softwareprojekt startet nicht möglichst laut, sondern möglichst klar. Vor dem ersten Sprint müssen Zielbild, Scope, Nutzerbedarf, Verantwortung, Roadmap und technische Risiken so weit sichtbar sein, dass die erste Etappe tragfähig wird. Wenn diese Basis fehlt, ist Discovery kein Umweg, sondern der kürzeste Weg zu einem Projekt, das später wirklich lieferbar bleibt.