Anforderungen managen in Projekten
Wissen Sie, ob Sie mit Ihrem Produkt oder Service die Wünsche Ihrer Kunden treffen? Investieren Sie Zeit und Geld, um eindeutige Anforderungen zu formulieren. Wie gehen Sie am besten vor? Dieser Artikel beschreibt, wie Sie Anforderungen in klassischen oder agilen Projekten managen.
Wie entstehen Anforderungen?
Anforderungen für Projekte entspringen unterschiedlichen Quellen:
- Visionen, Ziele oder Ideen, die Teil des Unternehmensauftrages sind
- Optimierungen und Verbesserungen der Prozesse im Unternehmen
- Produkt- oder Serviceideen von Kunden und Nutzern
- neue Vorschläge aus dem Lifecycle oder betriebliche Anforderungen
- Änderungen zu rechtlichen, technologischen, prozessualen oder organisatorischen Rahmenbedingungen
Die Auftraggeber können aus dem gesamten Unternehmensumfeld kommen. Aus deren Visionen, Ideen, Vorschlägen und Bedürfnissen entstehen erst während der Projektarbeit konkrete Anforderungen. Wegen ihrer unterschiedlichen Herkunft müssen sie konsolidiert und untereinander abgestimmt werden.
Idealerweise bündelt eine zentrale Stelle des Unternehmens die Fragmente oder Vorhaben und bewertet, ob es sich überhaupt lohnt, sich damit weiter zu beschäftigen.
Ein Trichter illustriert den Vorgang der Auslese: Zunächst nimmt er alle Visionen, Ideen, Wünsche und Fragmente auf und filtert diejenigen, die in den Unternehmensauftrag einzahlen. Die Elemente, die es durch die enge Öffnung schaffen, werden in einer Liste gesammelt.
Ein Gremium, bestehend aus Mitgliedern der Unternehmensleitung, entscheidet, ob die Anforderungen in einem Projekt realisiert werden sollen.Die Art und Weise des Vorgehensmodells, des zu startenden Projektes, entscheiden Auftraggeber und Projektleiter.
Drei Vorgehensmodelle haben sich etabliert: klassisch, agil oder hybrid. Kreativitätstechniken wie Brainstorming oder Design Thinking helfen, Anforderungen zu generieren.
Klassisches Anforderungsmanagement
Der klassische Projektleiter folgt dem Wasserfallmodell, das heißt, er arbeitet in den Phasen Initiierung, Planung, Realisierung, Kontrolle und Einführung. Ist eine Phase abgeschlossen, folgt die nächste. Rücksprünge in frühere Phasen können ressourcenintensiv sein, lassen sich aber nicht vermeiden.
Der Aufwand, Anforderungen zu beschreiben, ist während Initiierung und Planung am intensivsten. In diesem Zeitraum spezifiziert der Anforderungsmanager Wünsche, Ideen und konkrete Vorstellungen an Funktionen eines Produktes oder Services.
Das wäre auch zu einem späteren Zeitpunkt möglich, ist jedoch kostenintensiv. Denn ein Gremium müsste diese zunächst bewerten, ob und wie sie in den bestehenden Kontext passen. In der Praxis ist es normal den Projektinhalt auszuweiten, ohne jedoch den geplanten Liefertermin oder das Budget anzupassen.
Der klassische Anforderungsmanager erstellt ein Lastenheft, das sowohl die funktionalen (Was soll eine System können oder leisten?) als auch die nicht-funktionalen Anforderungen (Welche Qualitätsparameter sind einzuhalten?) enthält.
Schritt für Schritt verbessert der Anforderungsmanager den Detaillierungsgrad. Er kommuniziert ständig mit Fachkollegen und Anforderern. Dabei arbeitet er an den Formulierungen und schärft sie, bis sie unmissverständlich und frei von Interpretationen sind. Das fertige Anforderungsdokument schließt er mit einem formalen Treffen, dem Sign-Off Meeting, ab.
Wenn alle Betroffenen und Beteiligten dem Inhalt des Papiers zugestimmt haben, friert der Anforderungsmanager den Status ein. Damit sind alle Anforderungen fixiert und dienen den Entwicklern als Planungssicherheit.
Anforderungsmanagement im agilen Umfeld
Der Product Owner ist für den kommerziellen Erfolg im agilen Projektmanagement verantwortlich. Er kreiert die Produktversion und erstellt daraus das Product Backlog.
Im klassischen Projektmanagement würde es das Lastenheft darstellen. Die Elemente des Product Backlog beschreiben den Leistungsumfang des Produktes oder des Services. Da sich der Product Owner an den Werten des agilen Manifestes orientiert, achtet er auf höchsten Kundennutzen. Das Team unterstützt ihn bei dieser Arbeit.
Das Product Backlog als Anforderungsquelle beinhaltet User Stories. Diese sind nach Priorität aus Kundensicht sortiert, das heißt, die wichtigsten Wünsche, Ideen und Forderungen stehen ganz oben auf der Liste. Das Product Backlog ist ein lebendes Dokument, es kann niemals vollständig sein. Denn nach jedem Sprint kommen neue Einträge dazu oder alte verschwinden.
Mit anderen Worten: Das Backlog beinhaltet zunächst bekannte und realisierbare Anforderungen, die sich im Zuge der Produktentwicklung weiterentwickeln. Im späteren Verlauf erscheinen weitere Anforderungen, die zu einem frühen Projektzeitpunkt nicht sichtbar waren. Im Gegensatz zum klassischen Anforderungsmanagement sind neue Anforderungen über den gesamten Projektablauf willkommen.
Wesentlicher Bestandteil des Product Backlog sind User Stories. Sie helfen, die Bedürfnisse des Kunden oder Nutzers zu beschreiben. Jedoch auch Anforderungen an technische Systeme und deren Schnittstellen zu benachbarten Hard- und Softwareelementen beschreibt der Product Owner mithilfe von User Stories.
Sie dienen auch als Transportmittel für Diskussionen im Team. In diesen Gesprächen wird den Mitarbeitern der Kundenwunsch klarer. Mit diesem Verständnis entwickeln sie das, was der Kunde wirklich braucht.
In der Praxis hat es sich als sinnvoll erwiesen, User Story auf Story Cards zu notieren. Dabei versucht der Schreiber, diese W-Fragen zu beantworten:
- Wer (Rolle) fordert etwas an?
- Was (Funktion) wünscht sich der Anforderer?
- Warum (Nutzen) ist das für den Geschäftsfall wichtig?
Tipps für Anforderungsmanager und Product Owner
Im Folgenden möchte ich einige Erfahrungswerte vermitteln. Sicherlich lässt sich die Liste fortführen. An dieser Stelle konzentriere ich mich auf die wichtigsten Erfahrungen aus der Praxis.
- In beiden Vorgehensmodellen des Projektmanagements sind Anforderungen marktgetrieben, wobei im agilen Projektmanagement der Kundennutzen immer an erster Stelle steht.
- Sammeln Sie Visionen, Ideen, Wünschen und konkrete Vorhaben in einem klassischen Lastenheft. Wenn Sie im agilen Umfeld arbeiten, nutzen Sie das Product Backlog.
- Investieren Sie Zeit und Geld, um unmissverständliche Anforderungen zu formulieren. Bitte denken Sie daran: Ist die Anforderung mangelhaft, wird das Produkt mangelhaft sein.
- Für beide Vorgehensmodelle, klassisch und agil, gilt: Kommunikation mit allen Betroffenen und Beteiligten ist zwingend notwendig. Somit erhält der Kunde das Produkt oder den Service, den er sich gewünscht hat. Binden Sie alle Beteiligten, Stakeholder, rechtzeitig ein. Denn niemand möchte vor vollendete Tatsachen gestellt werden, wenn er direkt betroffen ist.
- Nutzen Sie linguistische Grundlagen, um die Verständlichkeit Ihrer Anforderungen zu optimieren. Für die klassische Arbeitswelt helfen Satzschablonen (PDF), um Missverständnisse zu vermeiden.
- Erstellen Sie eine Roadmap für Anforderungen, indem sie das KANBAN-Board dafür nutzen. Aus der Roadmap lässt sich ablesen, welchen Reifegrad die Anforderung besitzt.
- Sorgen Sie als Product Owner dafür, für das Team, insbesondere vor und während der Sprints, präsent zu sein, um jederzeit Rückfragen beantworten zu können.
- Wenn Sie in einem Großprojekt arbeiten, das aus vielen Teilprojekten besteht, die nach unterschiedlichen Vorgehensmodellen organisiert sind, dann wäre ein übergeordnetes Anforderungsmanagement hilfreich. Es sollte die generischen, strategischen Anforderungen bündeln. An seinen Leitplanken können Projektleiter und Product Owner ihre Projektarbeit ausrichten.
Quelle: kayenta.de
Themen: Klassisches Anforderungsmanagement, Agiles Anforderungsmanagement, Agiles Projektmanagement
