Warum manche Anforderungen erst im Projekt entstehen

Wer schon einmal ein größeres Digitalprojekt begleitet hat – sei es die Einführung eines neuen CMS, ein Relaunch oder die Auswahl einer neuen Plattform – kennt die Situation: Wochenlang werden Anforderungen gesammelt, Workshops durchgeführt und Fachbereiche befragt. Es entsteht ein umfangreiches Lastenheft, ein Anforderungskatalog oder Briefing, das scheinbar alle relevanten Punkte enthält. Trotzdem tauchen im Projekt plötzlich neue Anforderungen auf.

Für manche Projektverantwortliche fühlt sich das zunächst wie ein Fehler an. Wurde etwas übersehen? War die Anforderungsaufnahme unvollständig? Hätte man genauer fragen müssen?

Unsere Erfahrung zeigt: Nicht unbedingt.

Eine saubere Anforderungsaufnahme bleibt die wichtigste Grundlage für jedes Projekt. Je besser die Vorbereitung, desto geringer ist das Risiko von Überraschungen während der Umsetzung. Aus diesem Grund investieren Unternehmen und Agenturen viel Zeit in Workshops, Interviews und Analysen. Es werden Prozesse betrachtet, Systeme untersucht und Ziele definiert. In den meisten Fällen entsteht dadurch bereits ein sehr belastbares Bild.

Oft sind das bereits:

• die wichtigsten Geschäftsanforderungen

• relevante Prozesse

• bekannte Schnittstellen

• technische Rahmenbedingungen

• strategische Ziele

Mit einer guten Vorbereitung erreicht man häufig bereits einen sehr hohen Reifegrad der Anforderungen. Trotzdem bleiben Lücken. Nicht weil jemand schlecht gearbeitet hat, sondern weil bestimmte Dinge im Alltag schlicht selbstverständlich geworden sind.

Interessanterweise sind es oft nicht die komplexen Sonderfälle, die übersehen werden. Viel häufiger fehlen die Dinge, die jeden Tag genutzt werden. Wer seit fünf oder zehn Jahren mit einem System arbeitet, hinterfragt bestimmte Funktionen nicht mehr. Sie sind einfach da. Niemand denkt darüber nach, dass sie überhaupt existieren.

Erst wenn ein neues System eingeführt oder ein Prozess neu gedacht wird, tauchen Fragen auf wie:

• Woher kommen diese Daten eigentlich?

• Warum erscheint diese Information automatisch?

• Welche Schnittstelle liefert diese Inhalte?

• Wer nutzt diesen Export eigentlich?

Plötzlich stellt sich heraus, dass hinter einer vermeintlichen Selbstverständlichkeit ein wichtiger Prozess steckt. Genau deshalb entstehen manche Anforderungen erst während des Projekts.

Eine Methode hat sich in unseren Projekten immer wieder bewährt: die gemeinsame Sichtung des bestehenden Systems mit den Menschen, die täglich damit arbeiten, denn zwischen der Beschreibung eines Prozesses und der tatsächlichen Nutzung liegen oft Welten. In einem Workshop wird vielleicht gesagt: „Wir pflegen hier unsere Inhalte ein.“ Sobald man sich jedoch daneben setzt und zusieht, wie diese Aufgabe tatsächlich erledigt wird, entstehen plötzlich zahlreiche neue Fragen.

Woher kommen die Daten? Warum wird an dieser Stelle ein Excel-Export erzeugt? Weshalb wird zwischen drei verschiedenen Masken gewechselt? Und warum wird eine Information erst manuell in ein anderes System übertragen? Genau in diesen Momenten entstehen häufig die wertvollsten Erkenntnisse.

Während Anwender ihre tägliche Arbeit ausführen, werden viele Dinge sichtbar, die zuvor als selbstverständlich galten und deshalb nie als Anforderung formuliert wurden. Oft handelt es sich dabei nicht einmal um große Funktionen oder komplexe Prozesse, sondern um kleine Details, die für den Alltag enorm wichtig sind.

Typische Erkenntnisse aus solchen Systemsichtungen sind:

• bislang unbekannte Schnittstellen oder Datenquellen

• manuelle Arbeitsschritte, die automatisiert werden könnten

• wichtige Funktionen, die niemand im Workshop erwähnt hat

• Sonderfälle, die nur wenige Personen kennen

• technische Abhängigkeiten, die im Alltag kaum noch wahrgenommen werden

Besonders spannend ist dabei, dass die Fragen häufig nicht von den Anwendern selbst kommen, sondern von den Menschen, die das System zum ersten Mal sehen. Gerade dieser unverstellte Blick von außen führt oft zu den berühmten Aha-Momenten auf beiden Seiten. Deshalb sind Systemsichtungen für uns häufig ein fester Bestandteil der Anforderungsaufnahme. Sie helfen dabei, Anforderungen nicht nur zu diskutieren, sondern tatsächlich zu beobachten. Oft werden genau dort die letzten zehn Prozent sichtbar, die in keinem Workshop und in keinem Lastenheft auftauchen würden.

Viele Unternehmen betrachten die Anforderungsphase und den Projektstart als zwei voneinander getrennte Welten. Dabei beginnt die eigentliche Erkenntnisgewinnung häufig erst dann, wenn die zukünftige Agentur oder der Implementierungspartner involviert wird, denn nun kommen Menschen ins Projekt, die bisher nicht beteiligt waren.

Diese stellen Fragen wie:

• Warum macht Ihr das so?

• Was passiert danach?

• Wo landen diese Daten?

• Wer nutzt diese Information später?

Fragen, die intern oft niemand mehr stellt. Gerade deshalb sind Kick-offs und Initialisierungsworkshops so wertvoll. Sie dienen nicht nur dazu, Anforderungen zu bestätigen, sondern auch dazu, das gemeinsame Verständnis zu schärfen und blinde Flecken sichtbar zu machen.

Viele Projektverantwortliche erschrecken, wenn während der Umsetzung weitere Anforderungen auftauchen. Dabei ist die entscheidende Frage nicht, ob neue Erkenntnisse entstehen, sondern wann. Wer eine wichtige Anforderung in den ersten Workshops oder während der Konzeptionsphase entdeckt, hat eigentlich etwas gewonnen. Das Projekt wird dadurch besser. Kritisch wird es erst, wenn wesentliche Anforderungen kurz vor dem Go-live oder sogar danach sichtbar werden.

Deshalb gilt: Je früher neue Erkenntnisse auftauchen, desto besser lassen sie sich einordnen, priorisieren und umsetzen.

Natürlich sollte das Ziel immer sein, möglichst viele Anforderungen bereits vor Projektbeginn zu erfassen. Lieber wird eine Anforderung einmal zu viel dokumentiert als einmal zu wenig.

Wichtig ist dabei:

• Prozesse vollständig betrachten

• Selbstverständlichkeiten hinterfragen

• Fachbereiche früh einbeziehen

• technische und organisatorische Perspektiven zusammenbringen

Trotzdem wird es kaum ein Projekt geben, bei dem während der Umsetzung keine neuen Erkenntnisse entstehen und das ist völlig normal.

Ein gutes Briefing oder Lastenheft muss nicht perfekt sein. Es muss eine belastbare Grundlage schaffen, auf der ein Projekt starten kann. Wenn dann während der ersten Workshops weitere Anforderungen entdeckt werden, ist das kein Zeichen für schlechte Vorbereitung. Oft zeigt es sogar, dass die richtigen Fragen gestellt werden. Die eigentliche Qualität eines Projekts zeigt sich nicht daran, dass niemals neue Anforderungen entstehen. Sondern daran, dass sie früh erkannt, richtig bewertet und sinnvoll in die weitere Planung integriert werden.

Denn am Ende gilt: Je besser die Vorbereitung, desto weniger Überraschungen gibt es. Aber ganz ohne Überraschungen kommt kaum ein erfolgreiches Projekt aus.