Geht eine neue Projektanfrage bei uns ein, ist meist eine Leistungsbeschreibung mit mehr oder weniger detaillierten Anforderungen angehängt. Mal sind diese nur grob skizziert, mal sind es umfangreiche Listen mit endlos vielen Einzelanforderungen. Insbesondere, wenn es um die Auswahl eines neuen Conten-Management-Systems für eine Website geht, sind die Anforderungen detailliert, durchnummeriert und manchmal sogar priorisiert. Sehr selten hingegen steht dabei, welches Ziel die einzelne Anforderung verfolgt.

Solche Anforderungskataloge entstehen aus guten Absichten. Alle Abteilungen sollen gehört werden, niemand von ihnen darf übergangen werden. Am Ende liegt ein Dokument vor, dem alle zustimmen. Für die Angebotserstellung heißt das: Ich soll einen Preis benennen für etwas, dessen Nutzen niemand beziffert hat. Für das Unternehmen bedeutet das: Das Projektbudget verteilt sich auf Positionen, die unterschiedlich viel bewirken.

Zustimmung ersetzt keinen Nutzennachweis

In Vorgesprächen frage ich deshalb früh nach dem Warum hinter einzelnen Punkten. Die Antworten fallen unterschiedlich aus. Bei manchen Anforderungen folgt sofort ein Ziel, eine Zahl oder ein konkreter Arbeitsschritt, der entfallen würde. Bei anderen entsteht eine Pause. Und dann vielleicht noch der Hinweis, dass die Fachabteilung das so eingebracht habe.

Beides ist legitim. Aber der Unterschied zählt: Eine Anforderung, der niemand widerspricht, wirkt zunächst harmlos. Sie kostet nichts, solange sie auf dem Papier steht. In der Umsetzung konkurriert sie aber dann mit Punkten, die tatsächlich Auswirkungen haben, auf Budget, Zeit und Aufmerksamkeit.

Vier Fragen vor Projektbeginn

Um in diesem Punkt Klarheit zu schaffen, braucht es kein aufwendiges Verfahren. Vier Fragen genügen:

• Welche Anforderungen zahlen direkt auf ein konkretes Ziel ein?
• Welche sind „nice to have”, und warum stehen sie trotzdem auf der Liste?
• Können Sie für jede Anforderung den erwarteten Nutzen benennen?
• Was würde passieren, wenn Sie die Hälfte der Anforderungen streichen?

Es geht darum, jede Anforderung mit einem Ziel zu begründen. Wo das leichtfällt, steht ein Business Case dahinter. Wo die Begründung ausweicht, liegt eine Wunschliste vor.

Streichen bringt Erkenntnis

Die letzte Frage stelle ich besonders gern, weil sie effektiv aufzeigt, was tatsächlich Relevanz hat. Wer eine Anforderung testweise streicht und sofort erklären kann, welches Ziel dadurch verfehlt würde, hat ihren Wert verstanden. Wer hingegen nur auf Zuständigkeiten oder alte Absprachen und Zustände verweist („das war schon immer so“), liefert auch eine Antwort.

Für Auftraggeber lohnt sich diese Überlegung und Übung vor allem wirtschaftlich. Im Vorgespräch ist das Streichen eine Entscheidung. Nach der Umsetzung ist es jedoch eine Korrektur, die bereits Geld gekostet hat oder im schlimmsten Fall sogar das Projektziel gefährdet.

Begründen, was gebaut wird

Ein Business Case priorisiert also Wirkung, eine Wunschliste sammelt Ideen. Der Unterschied zeigt sich daran, ob sich für jede Anforderung erklären lässt, warum sie gebraucht wird und was sie bewirken soll.

Auf den Punkt gebracht: Nicht alles, was möglich ist, sollte umgesetzt werden. Diese Einsicht spart erfahrungsgemäß mehr Budget als jede Verhandlung über Tagessätze.