Umfrageergebnis: Die besten Ergebnisse erzielen Sie mit gemeinsamer Verantwortung für Anforderungen

Wer sollte die Verantwortung für Anforderungen tragen?
  • Die IT,
  • der Fachbereich,
  • beide gemeinsam?

Diese Frage wird durch eine Umfrage beantwortet. Das Ergebnis ist eindeutig: durch gemeinsame Verantwortung (Jointly Owned) für Anforderungen werden die mit Abstand besten Ergebnisse erzielt. Allerdings ist auch hier noch „Luft nach oben“, d.h. Budget wird überzogen, Termine werde nicht eingehalten und Stakeholder werden länger in Anspruch genommen als geplant.

Budgeteinhaltung (budget in % of target)
Die Einhaltung des Budgets liegt zwar jeweils über dem angestrebten Zielwert. Aber die Fachabteilungen (Non-IT Business) benötigen fast das doppelte Budget (196,5%), wenn sie alleine in der Verantwortung für Requirements stehen. Eine gemeinsame Verantwortung liefert das vergleichsweise beste Ergebnis (143,4% vom Zielwert).

Zeitlicher Verzug (time in % of target)

Alle drei Konzepte liegen deutlich über dem angestrebtem Termin. Mit gemeinsamer Verantwortung wird immerhin das beste Resultat erzielt (159,3% vom Zielwert).

Funktionalität (functionality in % of target)

Hier ist die Spannbreite am geringsten.
Bestätigen sich hier Klischees, dass die IT weniger Funktionen liefert als beauftragt (91,4%), bzw. dass der Fachbereich sich mehr wünscht, als er eigentlich braucht (110,1%)? 😉

Zeitbedarf der Stakeholder (stakeholder time in % of target)

Diesen Punkt finde ich eine interessante Ergänzung zum klassischen Dreieck Kosten – Zeit – Qualität. Wie lange werden die Stakeholder in Anspruch genommen, z.B. für die Anforderungsermittlung. Auch hier liegen die Ergebnisse über den Zielwerten. Eine gemeinsame Verantwortung für Anforderungen erreicht immerhin den vergleichsweise besten Wert (163,4% vom Zielwert).

Was sich aus der Umfrage nicht genau ergibt, ist, welche Verantwortung erfragt wurde (die Frage wurde nach Primary responsibility gestellt). Man kann unterscheiden zwischen fachlich-inhaltlicher und methodisch-syntaktischer Verantwortung für Anforderungen.

  • Fachlich-inhaltlich sollte der Anforderungssteller (häufig der Fachbereich) verantwortlich sein.
  • Methodisch-syntaktische Verantwortung sollte derjenige tragen, der die Anforderungen dokumentiert (häufig der Business Analyst bzw. Requirements Engineer).

Sieben Referenten berichten aus ihrer Praxis beim ibo-Trendforum „Anforderungsmanagement und Anforderungsanalyse“ am 11. November 2014. U.a. werden sie aufzeigen, wer in ihrem Unternehmen Verantwortung für Anforderungen trägt. Und sie berichten, wie sie erfolgreiches Anforderungsmanagement betreiben.

Wie sieht es bei Ihnen aus? Wer trägt bei Ihnen die Verantwortung für Anforderungen? Wo im Organigramm sind die Personen angesiedelt, die Anforderungen erheben und dokumentieren?
Schreiben Sie mir oder hinterlassen Sie unten einen Kommentar.

P.S. Auf welcher „Seite“ (Fachbereich oder IT oder neutral) arbeite ich als Business Analyst bzw. Requirements Engineer besser? Sollten die Personen, die Anforderungen ermitteln und dokumentieren, „neutral“ im Organigramm angesiedelt sein (und nicht direkt im Fachbereich oder der IT-Abteilung)?! Die o.a. Umfrageergebnisse lassen diese Schlussfolgerung zu. Den Vor- und Nachteilen der „Einsortierung“ von BAs bzw. REs im Organigramm habe ich in einem anderen Blogartikel nachgespürt.

Sie wollen mehr zum Thema Business-Analyse erfahren? Mit dem ibo-Newsletter bleiben Sie immer up to date!

3 Kommentare

  1. Leider konnte ich keine Angaben zur Befragungsmethode, zur Auswahl der Befragten (Wer wurde befragt, wo wurde befragt, wie wurde ausgewählt) bzw. überhaupt irgendwelche Informationen, die die Validität und Reliabilität der Ergebnisse bestätigen könnten finden.
    Gibt es dazu was?

    1. Hier die entsprechenden Angaben im Wortlaut: „The Business Analysis Benchmark report presents the findings from surveys of over 100 companies and definitive statistics on the importance and impact of business requirements on Enterprise success with technology projects. The survey focused on larger companies and looked at development projects in excess of $250,000 where significant new functionality was delivered to the organization. The average project size was $3 million.“

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert