Stakeholderanalyse Beispiel für Softwareprojekte

„Stakeholderanalyse Beispiel“ suchen viele dann, wenn sie nicht nur eine Definition wollen, sondern ein greifbares Bild dafür, wie eine Stakeholderanalyse in einem Softwareprojekt aussieht und wie sie sinnvoll ins Lastenheft gehört. Genau darauf zielt dieser Beitrag: Fachabteilungen und Projektverantwortliche, die zum ersten Mal ein Lastenheft schreiben, bekommen eine sofort nutzbare Orientierung für Angebote und interne Abstimmungen.

Mit Stakeholdern sind alle Personen oder Gruppen gemeint, die von der geplanten Software betroffen sind, Anforderungen einbringen, Entscheidungen treffen oder später mit dem Ergebnis arbeiten. Im Mittelpunkt steht keine Methodentheorie, sondern eine praktische Arbeitsgrundlage für Softwareprojekte, die neu geplant, abgelöst oder erweitert werden. Die vollständige Struktur eines Lastenhefts wiederholen wir dabei nicht; dafür verweisen wir an passender Stelle auf diese Lastenheft-Vorlage.

Warum sich ein Lastenheft vor der Angebotseinholung lohnt

Ein Lastenheft schafft vor der Anfrage an mehrere Anbieter eine gemeinsame Grundlage. Ziele, Rahmenbedingungen und Erwartungen liegen schriftlich vor. Dadurch werden Angebote besser vergleichbar, weil nicht jeder Anbieter etwas anderes unter derselben Aufgabe versteht. Gerade wenn Sie eine neue Software einführen, eine bestehende Lösung ablösen, eine vorhandene Anwendung erweitern oder Schnittstellen ergänzen wollen, spart diese Klarheit viele Rückfragen.

Besonders hilfreich ist dabei eine frühe Stakeholderanalyse. Sie macht sichtbar, wo Geschäftsführung, Fachbereich und IT unterschiedliche Erwartungen haben. Solche Unterschiede sind normal. Werden sie früh erkannt, lassen sie sich vor der Angebotseinholung klären, statt später im Projekt zu Änderungen oder Missverständnissen zu führen.

Wichtig ist außerdem: Ein Lastenheft muss kein technischer Bauplan sein. Es beschreibt die fachliche Sicht:

• was gebraucht wird
• warum es gebraucht wird
• woran die Erfüllung erkannt wird

Dazu gehören nicht nur gewünschte Funktionen, sondern auch Prozesse, Rollen, Datenquellen und Abhängigkeiten zu bestehenden Systemen. Erst so wird verständlich, wie die künftige Lösung in Ihren Arbeitsalltag passt.

Wenn Sie die vollständige Struktur suchen, hilft Ihnen diese Lastenheft-Vorlage. Für den nächsten Schritt nach dem Schreiben ist auch der Beitrag zur Anbieter-Auswahl nützlich.

Schritt für Schritt: Ziele, Beteiligte, Abläufe und Anforderungen

Beginnen Sie nicht mit Funktionen, sondern mit den Zielen. Halten Sie zuerst fest, was fachlich erreicht werden soll, was sich im Betrieb verbessern soll und welche konkreten Probleme heute bestehen. Typische Beispiele sind Medienbrüche zwischen Excel, E-Mail und Fachverfahren, doppelte Datenerfassung, fehlende Transparenz über Bearbeitungsstände oder unklare Verantwortlichkeiten. Genau diese Punkte gehören ins Lastenheft, weil sie später erklären, warum bestimmte Anforderungen wichtig sind. Wenn Sie dafür eine vollständige Gliederung suchen, hilft auch ein Blick auf dieses Lastenheft-Beispiel als Orientierung.

Der erste eigentliche Arbeitsschritt ist dann die Stakeholderanalyse. Sammeln Sie alle beteiligten Gruppen und notieren Sie zu jeder Gruppe drei Dinge:

• welchen Bezug sie zur künftigen Software hat
• welche Interessen und Erwartungen sie mitbringt
• welche möglichen Vorbehalte oder Risiken sichtbar sind

Ein kompaktes Stakeholderanalyse Beispiel für ein Softwareprojekt kann so aussehen: Bei einer kommunalen Webplattform zur Verwaltung eines Kanalnetzes ist das Bauamt oft der fachliche Treiber. Die Sachbearbeitung nutzt die Anwendung täglich und braucht eine einfache Erfassung und Pflege der Daten. Externe Dienstleister liefern Zustandsdaten oder Dokumentationen zu. Die IT achtet auf Betrieb, Zugriffe und die Einbindung in bestehende Systeme. Die Leitungsebene erwartet Auswertungen als Grundlage für Planung und Entscheidungen. Solche Konstellationen finden sich in ähnlicher Form auch in anderen Softwareprojekten und Einsatzbereichen.

Aus dieser Übersicht leiten Sie die Rollen im Lastenheft ab. Dabei geht es nicht um Stellenbezeichnungen, sondern um Aufgaben im Ablauf: Wer erfasst Daten? Wer prüft sie? Wer gibt Maßnahmen frei? Wer braucht Berichte? Wer verwaltet Nutzer und Rechte? Erst wenn diese Rollen sauber getrennt sind, lassen sich Anforderungen klar formulieren.

Im nächsten Schritt beschreiben Sie den Ist-Prozess. Das muss kein langer Fließtext sein. Oft reichen wenige Schritte: Wo entstehen Informationen, wie werden sie weitergegeben, wo werden sie manuell übertragen und an welchen Stellen entstehen Rückfragen oder Wartezeiten? Wichtig ist, Probleme am Prozess zu verorten, statt sofort Funktionen zu bestellen. So wird deutlicher, welche Lösung wirklich gebraucht wird und welche Wünsche nur Symptome beschreiben.

Erst danach formulieren Sie funktionale Anforderungen als kurze, verständliche Nutzenaussagen. Der Begriff User Story meint dabei eine kurze Beschreibung aus Sicht einer Rolle mit dem gewünschten Ergebnis. Beispiele sind:

• Zustände erfassen
• Maßnahmen planen
• Dokumente Vorgängen zuordnen
• Freigaben abbilden
• Berichte exportieren
• Termine nachverfolgen

Wenn aus solchen Anforderungen später ein Umsetzungsplan werden soll, zeigt das Pflichtenheft-Beispiel, wie daraus der nächste Schritt entsteht. Für eine erste Einordnung können Sie Ihr Vorhaben außerdem mit dem Kostenrechner grob einschätzen oder per Projekt-Check strukturieren lassen.

Wer mitarbeitet und wie Sie die Erstellung organisieren

An der Erstellung eines Lastenhefts wirken typischerweise mehrere Perspektiven mit. Der Auftraggeber oder die Geschäftsführung setzt Ziele und Prioritäten. Die Fachabteilungen beschreiben Abläufe, Probleme und Anforderungen aus dem Alltag. Die IT ergänzt, welche Systeme bereits vorhanden sind, welche Datenquellen berücksichtigt werden müssen und welche Randbedingungen für Betrieb und Zugriffe gelten.

Bei öffentlichen Auftraggebern oder in Agenturen kommen häufig weitere Beteiligte hinzu, etwa Vergabe- oder Projektverantwortliche. Sie helfen dabei, dass die Unterlagen vollständig, nachvollziehbar und strukturiert bleiben. Wenn Sie vor der Anfrage noch unsicher sind, was in die Unterlagen gehört, hilft der Beitrag zur Struktur der Anfrage.

Sinnvoll ist, eine Person als verantwortliche Redaktion zu benennen. Sie vereinheitlicht Begriffe, vermeidet Doppelungen und sammelt offene Fragen an einer Stelle.

Praktisch funktioniert die Erstellung oft so:

• Anforderungen in kurzen Workshops oder Interviews aufnehmen
• Ergebnisse zentral zusammenführen
• Entwürfe von den Beteiligten gegenlesen lassen
• Unterschiede offen markieren und priorisieren

Unterschiedliche Interessen sind dabei kein Problem, sondern normal. Genau dafür ist die Stakeholderanalyse da: Sie macht abweichende Erwartungen sichtbar und übersetzt sie in priorisierte Anforderungen.

Diese frühe Abstimmung erleichtert später auch den Angebotsvergleich, weil weniger Grundsatzfragen offenbleiben. Wenn Sie danach den passenden Anbieter auswählen möchten, lesen Sie als Nächstes diesen Beitrag zur Auswahl.

Lastenheft und Pflichtenheft: Wer schreibt was?

Das Lastenheft beschreibt aus Sicht des Auftraggebers, was erreicht werden soll. Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers, wie diese Anforderungen umgesetzt werden können. Diese Trennung ist für die Angebotseinholung wichtig: Anbieter können nur dann belastbar reagieren, wenn die fachlichen Erwartungen klar, vollständig und nachvollziehbar beschrieben sind.

Ins Lastenheft gehören deshalb in der Regel keine technischen Entscheidungen, keine Architektur und keine konkreten Umsetzungsvorschläge, solange sie nicht ausdrücklich als Rahmenbedingung vorgegeben sind. Es geht zunächst um Ziel, Nutzen, Rollen, Prozesse und Anforderungen.

Rückfragen eines Anbieters sind dabei kein Hinweis auf ein schlechtes Lastenheft. Häufig dienen sie dazu, Begriffe zu schärfen, Abhängigkeiten sichtbar zu machen oder Prioritäten zu klären.

Im nächsten Schritt kann daraus ein Umsetzungsplan entstehen, der Lösungsweg, Abhängigkeiten und Qualitätssicherung beschreibt. Wie das aussieht, zeigt der Beitrag zum Pflichtenheft im nächsten Schritt.