Anforderungsmanagement in IT-Projekten – Teil 1: Ein neues Projekt und viele offene Fragen

Wie beginnt eigentlich ein gutes Anforderungsmanagementprojekt? Oft mit Unklarheiten. Und mit Gesprächen – auf dem Sportplatz, in der Turnhalle oder zwischen zwei Terminen. Im Rahmen unserer Blogserie begleiten wir zwei erfahrene Köpfe – Architekt Adam (ARCH) und Anforderungsmanager Manfred (AM) – bei ihren Treffen im Alltag. Gemeinsam beleuchten sie typische Herausforderungen aus dem Anforderungsmanagement in IT-Projekten.

Wie alles begann: Architektur trifft auf Anforderung

Im ersten Teil geht es um den Startpunkt: Wie gelingt der Einstieg in ein komplexes IT-Projekt, bei dem eine öffentliche Ausschreibung vorbereitet werden soll?

Erstes Treffen: Anforderungsmanagement für eine Ausschreibung

Ort des Geschehens: Die Turnhalle beim Sport der Kinder – ein alltäglicher, entspannter Rahmen für ein Fachgespräch mit Tiefgang.

Hinweis: Der folgende Dialog ist Teil einer fiktiven Gesprächsreihe, die typische Rollen und Herausforderungen im Anforderungsmanagement realitätsnah beleuchtet.

ARCH: Na, Manfred, wie geht’s? Was macht die Kunst?
AM: Muss, und selbst? Was macht die Arbeit? Bist du endlich aus diesem ollem Wartungsprojekt raus?

ARCH: Ja, das war wirklich sehr langweilig, puh. Aber jetzt habe ich etwas Neues, allerdings wieder nicht das schöne „Grüne Wiese Projekt“, von dem wir alle träumen – zumindest noch nicht …
AM: Noch nicht? Wieso?

ARCH: Die Auftraggeberin, eine Behörde, möchte, dass wir die fachlichen und technischen Dokumente für eine darauffolgende Ausschreibung erstellen. Die Bestandslösung ist in die Jahre gekommen, nicht mehr wirklich wartbar und fachlich tragfähig. Die kommt aus einer Zeit, wo Digitalisierung ein Synonym für „irgendwie in Software und wie Akte und Karteikarte – nur am Computer“ war. Wenn wir etwas Glück haben und gute Arbeit machen, gewinnen wir ggf. später auch die Ausschreibung …
AM: Cool. Also sollte ihr faktisch ein Lastenheft mit dem Kunden erarbeiten?

ARCH: Ja, so nennt man das wohl. Spannende Sache, normalerweise kenne ich ja nur fertige Versionen solcher Dokumente – die in der Regel aber nie gut waren. Aus der Sicht der Behörde war dann die Standardantwort „Diskutieren sie nicht, schauen sie in die Spezifikation“, aber da fand ich nicht, was wir wissen mussten. Das führte zu Diskussionen und Mehraufwand, den wir dann an anderer Stelle sparen mussten oder wo die Auftraggeberin dann nochmals versuchen musste, weiteres Geld zu besorgen.
Jetzt habe ich mal die Chance, das besser zu machen. Aber im Team können wir uns nicht einigen, was wir denn jetzt genau wie machen, und was in das Dokument am Ende reingehört. Zu allem Überfluss haben wir nicht so viel Zeit, wie wir dachten. Wir können also nicht einfach mal anfangen, das muss schon von Anfang an sitzen.
AM: Aber nun ja. Eure Auftraggeberin muss doch gesagt haben, was sie für die Ausschreibung braucht und haben will – und was nicht. Ebenso sollte sie ja einschätzen können, was sie bereits weiß und nur noch aufgeschrieben haben will oder wo sie noch Hilfe braucht, z. B. in Form von Workshops oder technischer Beratung und Konzeption braucht.

ARCH: Nein, die macht das leider auch zum ersten Mal und hat daher auch noch keine wirklich konkreten Vorstellungen. Ich bin mir noch nicht sicher, ob ich unseren Vertrieb loben oder verteufeln soll, aber irgendwie hat er es geschafft, dass auch wir mit wenig Konkretem die Behörde als Kunden gewinnen konnten.
AM: Oh … und nu?

ARCH: Hmm, nächste Woche ist ein erstes Kennenlernen und wir brauchen langsam eine Agenda für diesen Termin aber auch einen Masterplan für die folgenden Termine … Was würdest du machen? Du bist da doch ein alter Hase?
AM: Na ja, erst einmal Kennenlernen klingt schon mal gut. Dann soll die Auftraggeberin sagen, warum sie das Projekt angeht. Was wird bezweckt? Welche Geschäftsziele verfolgt die Organisation und was sind Erfolgskriterien? Auch die Rahmenbedingungen sind wichtig. Wie groß soll das Projekt werden? Meist gibt es ja einen angestrebten finanziellen Rahmen für die Umsetzung. Aber auch für den späteren Betrieb? Gibt es bereits bekannte grundsätzliche Rahmenbedingungen?

ARCH: OK, das ergibt Sinn. Auf Basis der allgemeinen Projektbeschreibung hätte ich sogar schon erste Ideen. Ich würde daher ja gerne sofort mit den Umsetzungsdetails loslegen. Wieso brauche ich da „Geschäftsziele“? Das klingt ein wenig weit von der Technik entfernt. Ist das keine Zeitverschwendung? Ich dachte eher an konkrete Fragen zu Technologien, Qualitätsanforderungen, Sicherheitskriterien und natürlich auch zu den Use Cases.
AM: Immer langsam und eins nach dem anderen. Wenn du nicht weißt, warum dein Kunde Dinge macht, dann wirst du ihm irgendein, aber nicht ein auch wirklich passendes Lastenheft schreiben können. Und passend bedeutet erst einmal, dass am Ende deien Auftraggeberin mit den Ergebnissen zufrieden ist, weil ihre Behörde mit der neuen Lösung die erhofften Ziele auch erreicht. Du musst immer wissen, was deinen Kunden glücklich macht und vor allem was er braucht. Nur so kannst du ein Lastenheft schreiben, das ihn zufrieden stellt und gegen das du auch gerne entwickelst. Wenn du die Geschäftsziele verstanden hast, sind organisatorische Fragen zu klären. Wer sind deine Ansprechpartner, Verantwortliche und Entscheidungsträger? Wo soll das Projekt umgesetzt werden? Remote? Vor Ort? Welche Abstimmungsrunden und andere Regelmeetings gibt es? Wer entscheidet, wer muss mit einbezogen werden? Was ist die Verfügbarkeit der einzelnen Personen? Ich habe es schon mal gehabt, dass ein Keyplayer nur noch zwei Wochen da war, um dann den Rest der Projektphase z.?B. in Elternzeit zu sein.

ARCH: So habe ich das ja noch nie betrachtet, aber klingt eigentlich logisch. Ich versuche das mal zusammenzuschreiben und die ersten Gespräche mit dem Kunden so anzugehen!

Erkenntnis des Tages: Ohne Ziel kein Plan

Dieses erste Gespräch zeigt, wie wichtig es ist, nicht sofort mit der Lösung loszulegen, sondern das „Warum“ eines Projekts zu verstehen – gerade wenn die Ausschreibung noch vorbereitet werden muss. Die richtigen Fragen zu Beginn helfen, Risiken und Missverständnisse zu vermeiden und eine tragfähige Basis für das Lastenheft zu schaffen.

Wie geht es weiter?

In der nächsten Episode erfahren wir, wie das erste Treffen mit der Auftraggeberin gelaufen ist – und warum die Frage nach der richtigen Datenbank manchmal das falsche Gespräch eröffnet.

Bleiben Sie dran!

Bereits erschienen

Teil 1: Ein neues Projekt und viele offene Fragen
Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?
Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes
Teil 4: Was braucht man wirklich, um zu schätzen?
Teil 5: Testen vergessen?
Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!
Teil 7: Fazit und Ausblick