„Missverständnisse in der Kommunikation zwischen den Stakeholdern“
Dies ist der Hauptgrund für sich ändernde Anforderungen, als Ergebnis einer Umfrage. 77% der Befragten geben an, dass die Kommunikation immer oder oft nicht klappt. Verwunderlich ist es wohl nicht, zumindest deckt es sich mit meinen Erfahrungen. Es ist natürlich einfach, „kluge Ratschläge“ zu geben, wie z.B.: Kommunikation verbessert sich, indem man
- dem Gegenüber Feedback zum Gesagten gibt,
- die Aussagen mit eigenen Worten wiedergibt,
- einen Kommunikationsplan erstellt,
- wichtige Inhalte schriftlich festhält.
Gleichwohl werden diese grundlegenden Prinzipien zu oft nicht durchgeführt, sowohl in Projekten als auch bei (kleineren) Anforderungen im Tagesgeschäft.
„Wachsende oder sich ändernde Anforderungen ans Gesamtsystem (Produkt ändert sich, Zielgruppe ändert sich etc.)“
Mit 70% auf dem 2. Platz. Typischerweise werden dann Change Requests erstellt, analysiert, genehmigt, …
Hier mag Scope Modelling helfen, also die Abgrenzungen der zu ändernden Elemente (IT-Systeme, Geschäftsprozesse, Regelungen, …) von den nicht zu ändernden Elementen:
- Was soll oder muss geändert werden?
- Was braucht nicht oder darf nicht geändert werden?
Herausforderung ist häufig, die Grauzone zu minimieren. D.h. nicht für alle Elemente ist von Anfang klar, ob sie im Gestaltungsbereich (im Scope) sind oder außerhalb. Solange Elemente in dieser Grauzone sind, ist für die entsprechenden Anforderungen unklar, ob sie wichtig oder zu vernachlässigen sind.
„Pilotbetrieb, Prototyp, Analysen, zusätzliche Know-how-Träger etc. führen zu neuen Erkenntnissen“
Dieser Grund für sich ändernde Anforderungen auf Platz 3 ist wohl ein wesentlicher Grund dafür, dass agile Vorgehensmodelle immer öfter angewendet werden. Changes werden von vornherein als „natürlich“ angenommen.
Agiles Vorgehen ist sowohl strukturiert als auch mit klaren (Spiel-) Regeln ausgestattet. Dies ist wichtig, um z.B. Scrum erfolgreich durchzuführen.
Im Mittelfeld
Mit je 56% für sich ändernde Requirements werden die Gründe genannt
- „Machbarkeit falsch eingeschätzt“ und
- „Änderung von Randbedingungen (Priorisierung, Budgetierung, Marketingstrategie etc.)„
- Dicht gefolgt von „Zu abstrakte Formulierung (erfordert Detaillierung/Präzisierung der Anforderung)“ mit 52%.
Die ersten beiden Gründen liegen normalerweise nicht im Verantwortungsbereich eines Requirements Engineers oder Business-Analysten. Allerdings sollten REs und BAs sowohl auf Machbarkeit als auch auf Randbedingungen (bzw. Restriktionen) achten, weil dadurch ihre Aufgaben beeinflusst werden.
Für den dritten Grund „Formulierung von Anforderungen“ sind Requirements Engineers und Business-Analysten sehr wohl verantwortlich. Wobei sinnvollerweise zwischen einer inhaltlichen und formalen Verantwortung getrennt werden sollte. Inhaltlich verantwortet der Anforderungssteller die Anforderung, formal der RE bzw. BA. Zu abstrakte Formulierungen lassen sich durch konkrete Beispiele vermeiden, z.B. mittels Behaviour Driven Development.
„Änderung der Stakeholder-Zusammensetzung“
Dieser Grund tritt mit 22% vergleichsweise wenig auf: Ein Zeichen dafür, dass das Basiswerkzeug „Stakeholderanalyse“ wahrscheinlich oft angewendet wird. Eine Stakeholderanalyse kann eine Änderung der Zusammensetzung der Stakeholder nicht verhindern; allerdings hilft eine Stakeholderanalyse auf Änderungen vorbereitet zu sein.
Weitere Interessante Informationen rund um das Thema Business-Analyse warten auf unserer Homepage auf Sie!
Weitere Umfrageergebnisse und Studien
Rund um Anforderungen, Requirements Engineering, Business-Analyse:
- Die besten Ergebnisse erzielen Sie mit gemeinsamer Verantwortung für Anforderungen
- Was macht ein Business Analyst? Welche Aufgaben gehören zur Business Analyse?
Zu Projekten und Projektmanagement:
- Multiprojektmanagement – Erfolgsfaktoren und Herausforderungen
- Misserfolgsfaktoren in der Projektarbeit
- Ausschreibungen für Projektmanager sind oft unzureichend
- Projekte als Erfolgsfaktor für Unternehmen
- Was sind die wichtigen Weiterbildungsthemen im Projektmanagement?
Zahlen, Daten, Fakten zu Prozessmanagement:
Schließlich Erkenntnisse zu E-Learning, Blended Learning:
Ein, wie ich finde, sehr guter Kommentar erreichte mich auf einem anderen Kanal:
„Hallo Herr Naumann,
Warum werden denn nicht bei allen, resp. viel zu wenigen Firmen „wichtige Inhalte schriftlich festhalten“?
Liegt es
an der mangelnden Ausbildung,
hat die IT zu viele Quereinsteiger,
liegt es am Respekt für die benötigte Zeit der schriftlichen Ausarbeitung oder
ist es für Manager, REs, BAs nicht auch einfach angenehm in den Meetings zu sitzen und schwammig zu blieben, ohne konkret zu werden?
Oder, wen schickt man hin zum Extrahieren der Anforderungen zum Kunde?
A = mangelnde IT -Ausbildung
B = exzellente IT-Ausbildung
Kunde
Auftraggeber A | B
A — | –
B +- | ++
— wenn beide Seiten eine mangelnde Ausbildung haben, verstehen sich beide Seiten möglicher Weise menschlich recht gut, da keiner indirekt dem anderen suggeriert, er wäre inkompetent, aber das Ergebnis der Analyse wird mehr als mangelhaft sein, möglicherweise besteht schon daher kein Bedarf etwas aufzuschreiben
– wenn der Auftraggeber mangelnde Kenntnisse besitzt, kann möglicherweise der Auftraggeber bereits durch eine entsprechende Vorbereitung einigen Problemen entgegen wirken
+- mag der BA, RE möglicherweise durch geeignete Fragen und eine geübte Interview-Technik Informationen herauszulocken; möglicherweise kommt es aber auch im Gespräch zum Konflikt da der Auftraggeber erwartet, dass der Auftragnehmer Hellsehen kann und auch kein Verständnis für die Anzahl der zu klärenden Fragen besitzt
++ beide Seiten werden das entsprechende Verständnis für die Anforderungs-Analyse aufbringen und haben Freude am Analysieren, keiner wird sich durch entsprechende Fragen auf den Schlips getreten fühlen; auch die Nachbereitung/Konsistenzprüfung wird möglich, der Erhalt neuer Erkenntnisse aus dem Prototing wird einleuchten
Mit freundlichen Grüßen
P. S.“
Guten Tag Frau S.,
vielen Dank für Ihren Beitrag.
Die Gründe, warum „wichtige Inhalte nicht schriftlich festgehalten“ werden, sind vielfältig. Ich finde Ihre Analyse dazu sehr treffend.
Als Ergänzung erlebe ich noch, dass man sich an (Standard-) Anforderungs-Templates orientiert. Diese müssen ausgefüllt werden.
Dies ist auf der einen Seite natürlich sehr hilfreich, um eine Vergleichbarkeit und Standardisierung herbeizuführen. Andererseits birgt es die Gefahr, dass Informationen unberücksichtigt bleiben, die nicht in das Template passen (oder zu passen scheinen).
Viele Grüße
Axel Naumann