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....
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.