Manchmal sind es nicht die fehlenden Prozessbilder, sondern die fehlenden Schätzgrundlagen, die Projekte ins Stocken bringen. In Teil 4 unserer Gesprächsreihe mit Architekt Adam (ARCH) und Anforderungsmanager Manfred (AM) geht es um eine zentrale Frage: Welche Informationen sind wirklich nötig, um Aufwand und Architektur sicher kalkulieren zu können?
Viertes Treffen: Prozessbilder sind nicht genug
Ort des Geschehens: Wieder am Spielfeldrand. Diesmal wirkt Adam spürbar frustriert.
AM: Und…? Wie geht es dir heute?
ARCH: Oh man, es wird nicht besser. Unser Anforderungsmanager geht mir gerade ziemlich auf den Keks. Wir hatten ja intern besprochen, dass die Kollegen erst einmal mit dem Kunden abstimmen, wie die Applikation funktionieren soll, damit der Kunde meine technisch-orientierten Fragen anschließend besser beantworten kann. Das ist auch alles ganz nett, was sie da machen und hilft auch dem Kunden, aber es beantwortet keine meiner Fragen. Ich komme gerade nicht weiter. Schön, dass wir detaillierte Prozessbilder haben. Aber meine Frage ist eher, wie schnell ändern sich die Prozesse, wie soll die UI dazu aussehen? Das interessiert aber die Kollegen nicht. Was machen die da? Am Ende des Tages muss man auf Basis der Analyseergebnisse ja ein Angebot schreiben – und im konkreten Fall wollen wir ja auch teilnehmen und haben daher ein direktes Interesse, dass wir ein gutes Angebot machen. Aber trotz der vielen erfassten Informationen, habe ich nicht die Informationen, um eine angemessene Lösungsarchitektur zu erarbeiten und die Umsetzung dieser dann auch zu schätzen. Und so langsam wird die Zeit knapp…
AM: Naja, das ist grundsätzlich nicht falsch. Klar beschriebene Prozesse sind schon grundsätzlich ein wichtiger Aspekt für eine Umsetzung. Ich verstehe aber, dass sie nicht ausreichend sind, eine spezielle Umsetzung dieser zu identifizieren.
Mir scheint, ihr habt kein gemeinsames Bild, was ihr für den Kunden und auch für euch erreichen wollt und in welcher Reihenfolge ihr diese Dinge wann erreichen wollt? Was ist für den Kunden und euch heute das wichtigste? Was sind die zu erreichenden Ziele und was muss dafür getan werden – und was ggf. (noch) nicht? Welches Ziel versucht ihr denn deiner Meinung nach gerade zu erreichen?
ARCH: Äh …!? Hmm …
AM: Was ist dein Ziel?
ARCH: Wie gesagt…Ich stelle mir vor, dass ich irgendwann diese Ausschreibung selbst auf den Tisch habe und sie dann schätzen muss. Das ist mein grundsätzlicher Anspruch gegenüber dem Kunden und deckt sich aus meiner Sicht mit seinem Wunsch, ein wirtschaftliches Angebot für eine für ihn möglichst optimale Lösung von einem „guten“ Dienstleister zu bekommen. Dann hab ich meine Arbeit gemacht, dann ist der Kunde zufrieden und empfiehlt mich ggf. auch weiter oder spricht mich für andere Projekte wieder an. Dies funktioniert aber aktuell so noch nicht.
AM: OK. Das klingt spannend, da könnte ich auch noch was lernen. Lass uns das mal aufmalen (nimmt seinem Sohn eines der leeren Blätter, auf denen dieser zwischen den Spielen gerade malt, weg). Und schreibt „Schätzen“ auf das Blatt. Was brauchst du, um zu schätzen?
Arch: Ich muss eine konkrete architektonische Lösung im Kopf haben.
AM: Irgendeine?
ARCH: Nein. Eine angemessene, wirtschaftliche Lösung. Eine, die die Rahmenbedingungen und die Qualitätsanforderungen einhält und die Features des Kunden erfüllt.
AM: OK, das reicht doch aber nicht. Du kannst ja nicht einfach hingehen und sagen „5 Features => 5 Tage“. Du brauchst doch eine detaillierte Beschreibung der Features, um den Aufwand benennen zu können. Deswegen machen die Kollegen ja so einen Aufwand, oder?ARCH: [Grübelt] Nein! Das brauche ich nicht! Wir sind ja eine professionelle Firma und haben schon viele Projekte umgesetzt. Die Projekte sind sehr verschieden, aber viele, fast alle Projekte bestehen aus wiederkehrenden Bausteinen. In der Regel gibt es eine Handvoll Lösungen, die sich in ihren spezifischen Eigenschaften unterscheiden. Meist reicht es mir zu wissen, welche Lösung ich umsetzen muss, wie oft ich sie umsetzen muss und wie komplex sie aus Sicht der fachlichen Anforderungen jeweils ist. Nimm so ein Webformular: Für die Schätzung ist es egal, wie die Felder heißen. Wichtig ist eher die Anzahl der Felder, die Komplexität der Validierung und ob es ggf. besondere Merkmale wie z. B. Tabellen gibt. Da verstehe ich auch nicht, warum die Kollegen stundenlang um Namen ringen.
Oder nimm die Erstellung eines T-Shirts. Für die Bestimmung des Preises ist völlig egal, was für ein Motiv auf dem T-Shirt gedruckt wird. Entscheidend ist die Qualität des Materials, die Größe des T-Shirts, sowie ob es ein einfarbiger oder mehrfarbiger Druck ist. Ggf. ist es auch interessant, wie viele T-Shirts der Kunde will. Wenn der Kunde 50 Shirts haben will, kann ich einen anderen Preis machen, ggf. kann ich sogar in der Herstellung durch die Menge etwas effizienter werden, weil meine Mitarbeiter anders arbeiten können. Aber das konkrete Motiv brauch ich ggf. erst kurz vor dem Druck (also bei der Entwicklung), speziell wenn der Kunde sicherstellt, dass das Motiv bestimmte Eigenschaften z.B. bzgl. Größe und Auflösung einhält.
AM: Hmm, das ist interessant. Grundsätzlich ist das für mich ja nicht neu. Aber die Vehemenz deiner Aussage überrascht mich dann doch. Da muss ich mal drüber nachdenken.
Erkenntnis des Tages: Schätzen heißt Muster erkennen
Was Architekt Adam hier deutlich macht: Nicht jede Schätzung braucht jedes Detail. Oft reicht es, die Bausteine zu kennen, aus denen eine Lösung zusammengesetzt wird – und diese richtig zu klassifizieren.
Für das Anforderungsmanagement bedeutet das: Weg vom reinen Festhalten einzelner Fakten hin zu einer strukturierten Erfassung von Aufwandstreibern und Wiederholungsmustern. Das spart Zeit und schafft eine realistischere Basis für Angebote.
Wie geht es weiter?
Im nächsten Teil unserer Serie wird es noch praktischer: Adam erlebt hautnah, was passiert, wenn das Testen im Projekt zu spät auf die Agenda kommt. Ein Thema, das im öffentlichen Sektor besonders häufig übersehen wird – und dessen Konsequenzen weitreichend sein können.
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
