Um Stakeholder für deine IHK-Projektarbeit geht es in der achten Episode der Shorts des IT-Berufe-Podcasts.
Ich zeige dir in diesem Podcast-Short, warum Stakeholder für jedes IHK-Abschlussprojekt zentral sind: Von ihnen kommen die Anforderungen, an denen sich später die Qualität deines Projekts misst. Dabei solltest du nicht nur an Kund:innen und Benutzer:innen denken, sondern auch zum Beispiel an Projektleitung, Betrieb, Support, Datenschutz, Gesetzgeber, Sicherheitsverantwortliche, Management, externe Dienstleistende oder technische Rahmenbedingungen. Ich empfehle dir, alle relevanten Stakeholder systematisch zu sammeln, ihre Anforderungen zu dokumentieren und zu priorisieren, damit dein Projekt nicht an übersehenen Anforderungen scheitert.
Stakeholder und Anforderungen im IHK-Abschlussprojekt
Ich erkläre dir, warum die Stakeholder-Analyse in praktisch jedem Abschlussprojekt für die IHK-Prüfung wichtig ist. Egal ob du in der Anwendungsentwicklung, Systemintegration oder in einem kaufmännischen IT-Beruf arbeitest: Du brauchst eine Anforderungsanalyse. Dabei geht es darum, herauszufinden, wer was von deinem Projekt erwartet und welche Anforderungen daraus entstehen.
Die Anforderungen musst du aufnehmen, dokumentieren, priorisieren und konkretisieren. Sie sind entscheidend für den Projekterfolg, denn Qualität bedeutet: Grad der Übereinstimmung mit den Anforderungen. Wenn Anforderungen fehlen, unklar sind oder übersehen wurden, kannst du am Ende nicht sicher sagen, ob dein Projekt wirklich erfolgreich ist.
Was Stakeholder sind
Ich fasse Stakeholder als alle Personen, Rollen, Institutionen oder auch Rahmenbedingungen auf, die:
Interesse an deinem Projekt haben,
Einfluss auf dein Projekt haben,
oder von deinem Projekt betroffen sind.
Wichtig ist: Nicht alle denkbaren Stakeholder sind in jedem Projekt relevant. Die Liste soll dir helfen, mögliche Stakeholder nicht zu vergessen.
Warum Stakeholder oft übersehen werden
Ich beobachte häufig, dass Prüflinge nur an folgende Stakeholder denken:
Kund:innen beziehungsweise Auftraggeber:innen
Endbenutzer:innen
Dabei werden viele weitere Stakeholder vergessen, obwohl sie ebenfalls konkrete und teilweise harte Anforderungen an das Projekt haben. Wenn du nur einzelne Stakeholder berücksichtigst, kann dein Projekt später scheitern, weil wichtige Anforderungen fehlen.
Mögliche Stakeholder und ihre typischen Anforderungen
Kund:innen oder Auftraggeber:innen
Diese Stakeholder bezahlen das Projekt oder geben es in Auftrag. Ihre typischen Interessen sind:
Einhaltung des Budgets
Einhaltung von Terminen
Erreichen der Business-Ziele
Kund:innen sind nicht automatisch auch die Menschen, die das Ergebnis später benutzen.
Endbenutzer:innen
Das sind die Personen, die mit der Software oder dem System tatsächlich arbeiten. Ihre Anforderungen können ganz anders sein als die der Kund:innen, zum Beispiel:
einfache Bedienung
gute Performance
Zuverlässigkeit
Das gilt nicht nur für Software, sondern auch für Systeme in der Systemintegration.
Projektleitung
Auch die Projektleitung ist ein Stakeholder. In deinem IHK-Projekt kannst das auch du selbst sein. Mögliche Anforderungen sind:
Planungssicherheit
Risikominimierung
Reporting
Gerade im Prüfungsprojekt ist Planungssicherheit wichtig, weil du nur eine begrenzte Stundenzahl hast.
Entwickler:innen beziehungsweise Administrator:innen
Die Personen, die das System später weiterentwickeln oder betreiben, haben ebenfalls Anforderungen. Beispiele sind:
wartbarer Code
stabile Systeme
gute Testbarkeit
definierte Deployment-Prozesse
stabile APIs
eventuell Anforderungen an UX, UI oder Barrierefreiheit
Für die Systemintegration können zusätzlich wichtig sein:
hohe Verfügbarkeit
Skalierbarkeit
Monitoring
Alerts
IT-Betrieb und Support
Dieser Stakeholder wird oft vergessen, obwohl das System nach der Einführung meist über längere Zeit betrieben wird. Typische Anforderungen sind:
Wartbarkeit im Betrieb
Logging
Dokumentation
klare Prozesse für Fehlerfälle
Datenschutz und Compliance
Sobald dein Projekt in einem regulierten Umfeld stattfindet, können daraus verbindliche Anforderungen entstehen. Beispiele sind:
DSGVO-Konformität
Datensparsamkeit
Zugriffskontrollen
Monitoring
weitere organisatorische oder technische Vorgaben
Ich nenne auch zusätzliche Vorschriften wie Code-Reviews, Vier-Augen-Prinzip oder neue regulatorische Anforderungen.
Staat und Gesetzgeber
Je nach Branche gelten weitere gesetzliche Vorgaben, zum Beispiel:
Anforderungen an Barrierefreiheit
Aufbewahrungspflichten
revisionssichere Archivierung
Diese Vorgaben können sehr konkrete Anforderungen an Software oder Infrastruktur auslösen.
Sicherheitsverantwortliche
Im Unternehmen kann es Rollen geben, die Sicherheitsanforderungen vorgeben. Beispiele sind:
Zugriffsschutz
Verschlüsselung
Pentests vor dem Go-live
Solche Punkte musst du bei Zeit, Budget und Planung berücksichtigen.
Kulturkreis
Wenn Software international eingesetzt wird, entstehen Anforderungen durch Sprache und Nutzungskontext, zum Beispiel:
Übersetzungen
unterschiedliche Schreibrichtungen
Datumsformate
Zahlenformate
Management oder Geschäftsführung
Diese Stakeholder interessieren sich vor allem für die wirtschaftliche und strategische Seite des Projekts, zum Beispiel:
Amortisation
Return on Investment
strategische Passung
Budget und Portfolio
Skalierbarkeit
Externe Dienstleistende
Wenn externe Unternehmen beteiligt sind, können zusätzliche Anforderungen entstehen, etwa:
technische oder organisatorische Schnittstellen
Kommunikationswege
Service-Level-Agreements
Hardware beziehungsweise vorhandene Infrastruktur
Auch technische Rahmenbedingungen können wie ein Stakeholder wirken. Beispiele sind:
begrenzte CPU- oder RAM-Ressourcen
Netzwerklatenzen
begrenzter Speicherplatz
Diese Limitierungen beeinflussen direkt, wie du dein Projekt umsetzen kannst.
So kannst du in deinem Projekt vorgehen
Ich empfehle dir ein schrittweises Vorgehen:
Stakeholder sammeln
Überlege zuerst, wer Interesse an deinem Projekt haben könnte.
Stakeholder gruppieren
Zum Beispiel in intern und extern oder nach anderen sinnvollen Kriterien.
Repräsentierende Personen auswählen
Du kannst nicht mit allen sprechen, also such dir passende Ansprechpersonen oder Rollen aus, etwa Key-User:innen.
Anforderungen erheben
Das kann oft einfach über Gespräche passieren. Bei Gesetzen oder Spezialthemen kannst du auch Fachpersonen wie Datenschutz- oder Sicherheitsbeauftragte einbeziehen.
Anforderungen dokumentieren und priorisieren
Schreib die Anforderungen auf, formuliere sie einheitlich und priorisiere sie. Daraus kann zum Beispiel ein Lastenheft entstehen.
Widersprüche und Prioritäten prüfen
Später kannst du analysieren, welche Anforderungen besonders wichtig sind und ob es Konflikte zwischen ihnen gibt.
Beispiel aus einem kleinen Web-App-Projekt
Ich nenne zum Schluss ein einfaches Beispiel:
Benutzer:innen wollen eine einfache Oberfläche
Admins wollen zum Beispiel Rechteverwaltung, Security-Vorgaben und Logging
gesetzliche Vorgaben wie DSGVO müssen bei personenbezogenen Daten eingehalten werden
Selbst bei einem kleinen Projekt kommen also schnell mehrere Stakeholder zusammen.
Fazit
Ich mache deutlich, dass du in deinem Projekt nicht nur an Kund:innen oder Benutzer:innen denken solltest. Es gibt viele weitere mögliche Stakeholder, deren Anforderungen dein Projekt beeinflussen. Wenn du diese Anforderungen frühzeitig sammelst, dokumentierst und priorisierst, reduzierst du das Risiko, dass dein Projekt an übersehenen Anforderungen scheitert. Genau daran entscheidet sich letztlich auch, wie erfolgreich und qualitativ dein Projekt ist.
Links
Permalink zu dieser Podcast-Episode
RSS-Feed des Podcasts
Transkription der gesamten Episode
Automatisch erzeugte Transkription der Episode
[0:20] Heute möchte ich mich mal mit einem Thema beschäftigen, was in, ja, eigentlich allen IT-Abschlussprojekten für die IHK-Prüfung relevant ist, und zwar die Stakeholder bei deinem Projekt. Welche es da so gibt, was die für Anforderungen haben könnten und welche du vielleicht vergessen hast bei deiner Stakeholder-Analyse, darüber wollen wir heute mal sprechen, sehe ich nämlich ganz oft. Normalerweise gehört zu jedem IT-Projekt, egal welche Fachrichtung, Systemmitigation, Anwendungsentwicklung, kaufmännisch, ganz egal, müssen wir eine Ist-Analyse machen, eine Anforderungsanalyse, sorry, bringe ich ein bisschen durcheinander gerade, die Anforderungsanalyse. Um die soll es heute gehen. Das heißt, welche Anforderungen soll dein Projekt überhaupt umsetzen? Und das ist ganz egal, ob ich eine Software entwickle oder irgendein System installiere, konfiguriere oder irgendein Angebot berechne. Ganz egal, was ich für ein Abschlussprojekt habe, es geht immer darum, wer will eigentlich was haben und für wen mache ich das und was wollen diese, meistens sind es Menschen oder Rollen oder Organisationen, Institutionen können es auch sein, wir gleich nochmal sehen, was wollen die von mir? Was haben die für konkrete Anforderungen an mein Projekt? Und diese Anforderungen muss ich aufnehmen, die muss ich dokumentieren, die muss ich im besten Fall priorisieren, die muss ich verfeinern und konkretisieren. Mit diesen Anforderungen steht und fällt der Erfolg meines Projekts. Denn du kennst vielleicht noch aus einer der unzähligen anderen Episoden, wo ich das Thema angesprochen habe, die Definition von Qualität.
[1:39] Qualität ist der Grad der Übereinstimmung mit den Anforderungen. Und wenn ich keine Anforderungen habe oder die Anforderungen halb habe oder vergessen habe oder unklar habe, dann weiß ich gar nicht, ob ich qualitativ gearbeitet habe, ob ich fertig bin, ob das Projekt wirklich das tut, was es soll, weil ich eine Anforderung übersehen habe, vergessen habe etc....