Je weniger Meetings, desto agiler? Ein gefährlicher Trugschluss. Warum zu frühes Loslegen sogar Zeit frisst und wie Sie mit realistischen Abstimmungen, gezieltem Vorgehen und gesundem Pragmatismus zur tragfähigen Spezifikation kommen erfahren Sie in diesem Beitrag.
Wenn der Startschuss zur Stolperfalle wird
Montagmorgen, Kick-off eines neuen IT-Projekts. Die Entwickler:innen sind bereit, die Projektleitung erwartet erste Ergebnisse und jemand sagt, halb im Scherz: „Lass uns einfach mal anfangen, wir spezifizieren später.“
Ein Satz, der in vielen Teams ein vertrautes Gefühl auslöst – und gleichzeitig der Startschuss für spätere Missverständnisse, Nacharbeiten und unnötige Kosten ist. Denn so verständlich der Wunsch nach Schnelligkeit ist: Eine unklare oder lückenhafte Spezifikation kostet am Ende in der Regel deutlich mehr Zeit, als sie spart.
Spezifikation ist nicht gleich Wasserfall
Viele verbinden Spezifikation mit schwerfälligen Pflichtenheften und Bürokratie. Doch das ist ein Missverständnis. Auch in agilen Projekten ist eine fundierte Auseinandersetzung mit den Anforderungen entscheidend.
Eine Spezifikation heißt nicht, alles im Voraus wissen zu müssen – aber sie bedeutet, bewusst und gemeinsam Klarheit zu schaffen. Über das Ziel, den Kontext, die Anforderungen, Einschränkungen und kritischen Faktoren.
Sie gibt dem Projekt Struktur, fördert Verständnis zwischen den Beteiligten und verhindert Fehlentwicklungen. Und vor allem: Sie schafft Raum für echte Agilität – weil das Fundament stimmt.
Eine fundierte Spezifikation der Anforderungen ist auch in agilen Projekten entscheidend.
Der typische Weg zur tragfähigen Spezifikation
Basierend auf unserer Erfahrung in zahlreichen Kundenprojekten hat sich ein klarer Ablauf etabliert, der sich in vielen Situationen bewährt hat. Dieser Prozess führt Schritt für Schritt zur tragfähigen Spezifikation – und lässt dabei Raum für Iterationen, neue Erkenntnisse und notwendige Anpassungen:
1. Initiale Anforderungsaufnahme: Der Auftraggeber – häufig ein Produktverantwortlicher oder Stakeholder aus dem Fachbereich – formuliert erste Anforderungen und Erwartungen. Im Vordergrund stehen Zielbild, Nutzen und Rahmenbedingungen – nicht technische Details.
2. Discovery-Phase und Rückfragen: Architekt:innen, Entwickler:innen oder Projektleiter:innen steigen tiefer ein. Sie hinterfragen Annahmen, ergänzen Informationen und prüfen erste technische Aspekte. Häufig gehört hierzu auch ein kleiner PoC, um die Machbarkeit zu validieren – ein Aspekt, der oft unterschätzt wird, aber entscheidend sein kann. So entsteht ein gemeinsames Verständnis über das „Was“ und „Warum“ – mit einem realistischen Blick auf das „Wie“.
3. Strukturierung und erste Dokumentation: Die Anforderungen werden aufbereitet – etwa in Form von User Stories, Prozessmodellen oder Grobkonzepten. Werden hier Lücken oder Brüche sichtbar, zeigt das weiteren Klärungsbedarf auf.
4. Technische Vorarbeiten und Prüfung: Schnittstellen, Datenflüsse oder Machbarkeit werden frühzeitig beleuchtet. Erste Skizzen, Mockups oder Tests helfen, Risiken früh zu erkennen.4.
5. Abgleich und finale Abstimmung: In einer abschließenden Schleife stimmen sich alle Beteiligten – von IT über Fachbereich bis Geschäftsleitung – erneut ab. Ziel ist es, offene Punkte zu klären, Anforderungen zu priorisieren und ein gemeinsames Verständnis herzustellen.
Je nach Komplexität kann dieser Prozess zwei, fünf oder mehr Runden umfassen. Entscheidend ist nicht die Anzahl der Meetings, sondern die Qualität des Dialogs – und die Bereitschaft, iterativ Klarheit zu schaffen.
Aber wie viele Meetings braucht das wirklich?
Wir haben zahlreiche Projekte begleitet und ausgewertet. Unsere Erfahrung zeigt: Weniger als drei strukturierte Abstimmungen führen selten zu tragfähigen Spezifikationen – es sei denn, das Thema ist sehr simpel oder bereits vorab gut vorbereitet.
In komplexeren IT-Projekten sind fünf bis sieben Iterationen die Regel. Diese finden nicht zwingend in Form von klassischen Meetings statt, sondern verteilen sich auf Workshops, schriftliche Reviews, Rückfragen oder technische Prüfungen.
Und: Je mehr Beteiligte mit unterschiedlichen Perspektiven involviert sind – IT, Fachbereich, externe Dienstleister – desto höher ist der Kommunikationsbedarf. Und damit auch der Abstimmungsaufwand.
Weniger als drei strukturierte Abstimmungen führen selten zu tragfähigen Spezifikationen (Quelle: Adobe Stock –
Warum diese Abstimmungen entscheidend sind
Eine zu frühe oder oberflächliche Spezifikation führt regelmäßig zu teuren Nacharbeiten:
- Wenn Anforderungen zu vage sind, werden falsche Annahmen getroffen.
- Wenn Designvorgaben nicht mit dem technischen Rahmen kompatibel sind, entstehen Reibungsverluste.
- Und wenn Erwartungen nicht abgestimmt sind, drohen Frust, Schuldzuweisungen und sinkendes Vertrauen.
Eine saubere Spezifikation schafft dagegen die Grundlage für verlässliche Aufwandsschätzungen, realistische Projektplanung und effiziente Umsetzung.
Wie Sie mit weniger Reibung zur tragfähigen Spezifikation kommen
Planen Sie die Spezifikationsphase als bewusstes Arbeitspaket ein – nicht als Nebenschauplatz. Geben Sie allen Beteiligten den Raum, ihre Perspektiven einzubringen.
Achten Sie darauf, dass Anforderungen nicht mit fertigen Lösungen verwechselt werden. Eine klare Problembeschreibung ist oft hilfreicher als ein vorgeschlagener Lösungsweg.
Nutzen Sie schriftliche Dokumentation nicht als Bürokratieinstrument, sondern als Werkzeug zur Strukturierung und Verständigung. Je transparenter die Erkenntnisse festgehalten sind, desto besser die gemeinsame Orientierung.
Iterieren Sie gezielt – jede Abstimmungsrunde sollte Erkenntnisse bringen und offene Fragen reduzieren. Und holen Sie sich bei Bedarf externe Unterstützung: für Moderation, Strukturierung oder fachliche Übersetzung zwischen Business und IT.
Schneller starten ≠ schneller fertig
Der Wunsch nach Geschwindigkeit ist legitim – aber darf nicht zu Lasten der Klarheit gehen. Wer sich die Zeit für eine fundierte Spezifikation nimmt, spart sie später mehrfach wieder ein. Viele Projektverzögerungen lassen sich auf unklare, widersprüchliche oder nicht abgestimmte Anforderungen zurückführen. Eine gute Spezifikation ist deshalb kein Selbstzweck – sondern ein Hebel für Projekterfolg.
Und noch nie hat jemand gesagt: „Hätten wir mal weniger abgestimmt.“
flowciety hilft Unternehmen dabei, genau diesen Weg effizient zu gestalten – mit methodischer Tiefe, technischer Erfahrung und dem Blick für die relevanten Fragen. Damit aus Ideen verlässliche Lösungen werden.
Sichern Sie sich jetzt unser Whitepaper zur IT-Architektur – für bessere Planung, stabile Systeme und nachhaltige Projektsteuerung.
Quelle Titelbild: Adobe Stock – alfa27
Wir sind IT Partner
Unser Motto: IT im Geschäftsalltag als Lösung etablieren, nicht als Quelle von Problemen.
