Ein „Projekt Health Check“ bedeutet, ein Projekt systematisch auf Herz und Nieren zu prüfen. Im ersten Teil dieser Serie habe ich gezeigt, wie du die Team-Dimension bewertest. In diesem zweiten Teil geht es um einen weiteren kritischen Erfolgsfaktor: die Anforderungen. Denn selbst das beste Team kann scheitern, wenn die Anforderungen unklar, unvollständig oder schlicht überflüssig sind.

Ich habe in vielen Projekten erlebt, dass genau hier die größten Risiken lauern. Anforderungen, die nicht auf den Projektnutzen einzahlen, sind reine Zeit- und Geldverschwendung. Wenn Ziele und Nutzen nicht klar definiert sind, wird Priorisierung fast unmöglich. Und wenn Projekte lange dauern, sind die ursprünglichen Anforderungen oft schon veraltet, bevor sie umgesetzt werden. Besonders in klassischen Projekten kommt hinzu, dass Anwender ihre Anforderungen häufig nicht vollständig im Voraus formulieren können – viele Ergänzungen bzw. Verfeinerungen werden erst dann formuliert, wenn erste Ergebnisse sichtbar sind.

Deshalb arbeite ich auch hier mit einem strukturierten Health-Check-Framework, das die wichtigsten Aspekte abfragt und mir hilft, Problembereiche im Anforderungsmanagement frühzeitig zu erkennen. In diesem Beitrag zeige ich dir, worauf du achten solltest, und erläutere, warum diese Punkte so entscheidend sind.

Fehlender oder schwammiger Projektnutzen

Der Projektnutzen ist zwar nicht eine einzelne Anforderung, bildet aber das Fundament für alle weiteren Schritte im Anforderungsmanagement. Nur wenn der Nutzen klar und idealerweise messbar formuliert ist, lassen sich daraus eindeutige und sinnvolle Anforderungen ableiten. Eine bloße qualitative Aussage wie „Das System soll schneller werden“ reicht nicht aus – zielführend ist es, konkrete Verbesserungen zu benennen, etwa: „Die Erfassungszeit wird von 30 Minuten auf 10 Minuten reduziert.“ Wenn es mehrere Nutzen gibt, ist eine Priorisierung unerlässlich. So wird sichergestellt, dass die Anforderungen gezielt auf die wesentlichen Projektergebnisse einzahlen und der Fokus nicht verloren geht bzw. bei Widersprüchen die richtige Entscheidung getroffen wird.

Vollständigkeit der Anforderungen

Fehlende Anforderungen führen fast immer zu Nacharbeiten, Verzögerungen und Mehrkosten. In klassischen Projekten bedeutet das: Alle funktionalen und nicht-funktionalen Anforderungen müssen im Lasten- oder Pflichtenheft dokumentiert sein. In agilen Projekten ist entscheidend, dass alle relevanten Epics, Features und User Stories im Product Backlog erfasst und gepflegt werden.

Doch wie lässt sich die Vollständigkeit von Anforderungen überhaupt nachweisen? In der Praxis ist ein lückenloser Nachweis oft unmöglich – niemand kann mit absoluter Sicherheit belegen, dass wirklich nichts übersehen wurde. Deshalb habe ich mir vier pragmatische Ansätze zu eigen gemacht, die helfen, die Vollständigkeit zumindest plausibel abzusichern:

• Explizite Dokumentation von Nicht-Anforderungen: Es wird gezielt festgehalten, was bewusst nicht umgesetzt wird. So wird transparent, welche Anforderungen absichtlich außen vor bleiben und Missverständnisse werden reduziert.
• Analyse von Altsystemen: Falls bereits ein Vorgängersystem existiert, werden alle dortigen Prozesse systematisch betrachtet. Für jeden Prozess wird entschieden, ob er übernommen, verändert oder verworfen wird – so sinkt die Wahrscheinlichkeit, essenzielle Prozesse zu vergessen.
• Betrachtung von Gegensätzen: Für alle unterstützten Prozesse wird geprüft, ob das jeweilige „Gegenstück“ ebenfalls bedacht wurde, etwa Kauf und Stornierung, Versand und Rücknahme, Buchung und Storno. So bleiben keine offensichtlichen Lücken übersehen.
• Schnittstellen-Check: Gibt es angrenzende Systeme, werden die nötigen Schnittstellen gezielt abgeglichen. Offensichtliche Lücken, z.B. fehlende Verbindungen zu relevanten Nachbarsystemen, werden so frühzeitig entdeckt.

Diese vier Ansätze führen zwar nicht zu “absoluter” Gewissheit, sorgen aber für mehr Transparenz und eine nachvollziehbare Herleitung der Anforderungen. In Kombination mit den klassischen und agilen Methoden des Anforderungsmanagements entsteht so ein robuster Rahmen, um spätere Überraschungen zu minimieren.

Klarheit und Verständlichkeit

Unklare Anforderungen erzeugen Missverständnisse und falsche Implementierungen. Klassische Projekte setzen auf eindeutig formulierte, messbare Anforderungen, die von allen Stakeholdern freigegeben werden. In agilen Projekten sollten User Stories nach dem INVEST-Prinzip gestaltet sein und klare Akzeptanzkriterien enthalten, um eine gemeinsame Basis für die Umsetzung zu schaffen.

Gerade beim Thema Verständlichkeit stoßen Projekte häufig auf zwei zentrale Herausforderungen: Zum einen gibt es unterschiedlichste Zielgruppen – von Stakeholdern über Entwickler bis hin zu Testern – die jeweils verschiedene Perspektiven, Erwartungen und Informationsbedarfe mitbringen. Was für die eine Gruppe selbsterklärend ist, bleibt für eine andere oft unklar oder wird ganz anders interpretiert. Eine allzu technische oder fachlich abstrakte Dokumentation läuft Gefahr, an den tatsächlichen Bedürfnissen vorbeizugehen.

Zum anderen ist da die schiere Menge: Wer liest wirklich ein 200-seitiges Fachfeinkonzept, bevor es zur Freigabe kommt? Die wenigsten Stakeholder haben die Zeit oder Motivation, sich durch solch umfangreiche Dokumente zu arbeiten. Das erhöht das Risiko, dass wichtige Aspekte übersehen oder falsch verstanden werden – und Überraschungen sind dann fast programmiert. Auch wenn eine vollständige und nachvollziehbare Dokumentation wichtig ist, schützt sie allein nicht vor Missverständnissen oder späteren Änderungswünschen. Ein schlanker, zielgerichteter Dokumentations- und Review-Ansatz bleibt daher essenziell, um alle Beteiligten mitzunehmen und Klarheit zu schaffen.

Ausrichtung auf Projektziele, Priorisierung und Nachvollziehbarkeit

Anforderungen müssen auf die Projektziele einzahlen – sonst entstehen überflüssige Features. Um die Ausrichtung zu erleichtern und gleichzeitig eine Nachvollziehbarkeit zu erreichen, nutzen klassische Projekte eine Traceability-Matrix, die Anforderungen mit Zielen und Testfällen verknüpft. In agilen Projekten wird dieser Zusammenhang über die Produktvision, OKRs und Story Mapping sichergestellt.

Alle Projekte haben eine Gemeinsamkeit: Es gibt immer mehr Wünsche (Anforderungen) als Zeit und Budget, um eine Priorisierung kommt man nicht herum. Daher prüfe ich, ob es eine Priorisierung auf zwei Ebenen gibt.

• High-Level-Priorisierung: Hier stehen die vier grundlegenden Dimensionen im Mittelpunkt: Time (Zeit), Budget, Scope (Umfang) und Quality (Qualität). Sie bilden das magische Dreieck des Projektmanagements. Die Reihenfolge, in der diese Dimensionen priorisiert werden, muss individuell für jedes Projekt festgelegt werden – je nach Zielsetzung und Umfeld. In manchen Projekten steht etwa der Fertigstellungstermin (Time) über allem, in anderen ist der Umfang oder ein fixes Budget maßgeblich. Die bewusste Festlegung der Reihenfolge sorgt dafür, dass Zielkonflikte frühzeitig erkannt und Entscheidungen fundiert getroffen werden.
• Detail-Level-Priorisierung: Auf der operativen Ebene steht die Bewertung jedes einzelnen Features oder jeder Anforderung im Vordergrund. Hier hat sich die Unterscheidung nach Aufwand und Nutzen bewährt. Anforderungen mit hohem Nutzen und vergleichsweise geringem Aufwand sollten bevorzugt umgesetzt werden („Low Hanging Fruits“). Aufwändige Anforderungen mit wenig Mehrwert können zurückgestellt oder sogar entfernt werden. Methoden wie das WSJF-Prinzip („Weighted Shortest Job First“) oder einfache Aufwand-Nutzen-Matrizen helfen dabei, Transparenz in die Priorisierung zu bringen und Ressourcen gezielt einzusetzen.

Änderungsmanagement

Anforderungen ändern sich im Laufe eines Projekts – wer das nicht managt, riskiert Chaos oder veraltete Lösungen. Klassische Projekte arbeiten mit formalen Change-Request-Prozessen, die jedoch bei langen Laufzeiten oft zu starren Strukturen führen. Agile Projekte begegnen diesem Risiko durch regelmäßige Backlog-Refinements und transparente Kommunikation im Team.

Entscheidend im Health Check ist, wie strukturiert und transparent Änderungen am Anforderungskatalog gehandhabt werden. Dazu stelle ich mir drei zentrale Prüf-Fragen: Gibt es einen dokumentierten Change-Prozess, der klar beschreibt, wie Änderungswünsche erfasst, bewertet und umgesetzt werden? Wurde dieser Prozess im Projektverlauf tatsächlich genutzt und wie wurden die Auswirkungen auf Zeit, Kosten und Qualität gegenüber allen relevanten Beteiligten kommuniziert? Und speziell im agilen Kontext: Wie groß ist der Entscheidungsspielraum des Product Owners – ab wann werden Stakeholder aktiv einbezogen, um Tragweite und Auswirkungen von Änderungen fundiert abzustimmen? Diese Aspekte zeigen, wie reif das Änderungsmanagement ist und inwieweit Flexibilität und Steuerbarkeit in Einklang stehen.

Stakeholder-Abstimmung

Fehlende Einbindung der Stakeholder und Anwender führt zu Akzeptanzproblemen und Nachforderungen. Klassische Projekte binden Stakeholder in der Anforderungsdefinition ein, stoßen aber oft auf das Problem, dass Anwender ihre Bedürfnisse nicht vollständig im Voraus formulieren können. Agile Projekte lösen dieses Problem durch regelmäßige Reviews, in denen Feedback frühzeitig einfließt.

Ein zentrales Element für den Erfolg der Anforderungsanalyse ist nicht nur die formale Einbindung von Stakeholdern, sondern auch die Qualität und Intensität dieser Zusammenarbeit. Dabei lohnt es sich, im Health Check gezielt folgende Aspekte zu betrachten:

• Vertrauensbasis: Verfügen Product Owner oder Business Analysten über das Vertrauen der relevanten Stakeholder? Ohne diese Vertrauensbasis bleibt die offene Kommunikation eingeschränkt, und Bedürfnisse werden womöglich nicht ehrlich adressiert.
• Engagement-Messung: Wie viel Zeit und Energie investieren die Stakeholder tatsächlich in die Anforderungsanalyse? Bloße Unterschriften unter Dokumenten reichen nicht aus – entscheidend ist die aktive Mitwirkung, das Stellen von Rückfragen und die Bereitschaft zur Diskussion.
• Beteiligung und Diversität: Welche und wie viele Stakeholder sind regelmäßig in Sprint Reviews oder ähnlichen Feedback-Schleifen präsent? Eine breite, ausgewogene Vertretung verhindert einseitige Sichtweisen und erhöht die Akzeptanz der Ergebnisse.
• Qualität der Reviews: Finden in den Reviews echte Diskussionen statt und gibt es verwertbares Feedback? Werden kritische Punkte angesprochen – oder herrscht eher höfliches Abnicken? Nachhaltige Verbesserungen entstehen nur dort, wo Meinungsvielfalt ausdrücklich erwünscht ist und konstruktive Auseinandersetzung gefördert wird.

Die Beantwortung dieser Fragen gibt einen tiefen Einblick in die gelebte Stakeholder-Kultur eines Projekts und hilft, Risiken wie spätere Nachforderungen, verdeckten Widerstand oder fehlende Akzeptanz frühzeitig zu erkennen.

Überflüssige Anforderungen

Jede unnötige Anforderung kostet Zeit und Geld, ohne Mehrwert zu liefern. Klassische Projekte prüfen, ob alle Anforderungen auf den Projektnutzen einzahlen, während agile Teams regelmäßig Stories auf ihren Business Value hin überprüfen.

Tatsächlich ist es in der Praxis kaum möglich, mit absoluter Sicherheit festzustellen, ob eine Anforderung wirklich überflüssig ist – zu komplex und dynamisch sind die Rahmenbedingungen vieler Projekte. Was allerdings geprüft werden kann, ist das Bewusstsein für dieses Risiko im Team: Gibt es einen etablierten Prozess, der sicherstellt, dass Anforderungen regelmäßig hinterfragt und auf ihren Mehrwert überprüft werden? Sind transparente Kriterien definiert, nach denen entschieden wird, ob eine Anforderung verworfen oder weiterverfolgt wird? Nur wenn diese Fragen klar beantwortet werden können, wird aus der Theorie gelebte Praxis – und das Projektteam bleibt handlungsfähig, um sich auf das Wesentliche zu konzentrieren.

Fazit: Anforderungen gezielt im Blick behalten

Ein wirksamer Health Check im Anforderungsmanagement sorgt für Klarheit, Priorität und Transparenz – sei es in klassischen oder agilen Projekten. Entscheidend sind ein klar formulierter und messbarer Nutzen, vollständige und verständliche Anforderungen, strukturierte Priorisierung, ein flexibles Änderungsmanagement sowie die aktive Einbindung aller relevanten Stakeholder. Nur so lassen sich Risiken minimieren und Projekterfolge sichern.

Welche Herausforderungen kennst du aus deiner Praxis? Welche Strategien haben sich für dich bewährt, um Anforderungen erfolgreich zu steuern? Teile deine Erfahrungen gern in den Kommentaren!

In jedem Fall denk immer daran: Das Leben ist zu kurz, um in beschissenen Projekten zu arbeiten!