MORE Framework

Warum MORe

MORe entstand aus einer praktischen Lücke in komplexen IT-Projekten.

Viele Organisationen arbeiten agil, hybrid oder klassisch. Anforderungen werden in Backlogs, Tickets, User Stories, Fachkonzepten oder Lastenheften beschrieben. Trotzdem bleibt häufig unklar, ob eine Anforderung über ihren gesamten Lebenszyklus hinweg nachvollziehbar geführt wurde.

Im regulierten Umfeld reicht es nicht, Anforderungen nur zu erfassen und umzusetzen. Es muss nachvollziehbar bleiben, warum eine Anforderung entstanden ist, wer sie entschieden hat, wie sie umgesetzt wurde, wie sie getestet wurde, wer sie abgenommen hat und wann sie produktiv wurde.

MORe adressiert genau diese Lücke.

Die Lücke

Agile Lieferung erzeugt nicht automatisch regulatorische Nachweisfähigkeit.

Agile Arbeitsweisen helfen dabei, Arbeit sichtbar zu machen, Prioritäten zu setzen und regelmäßig Ergebnisse zu liefern.

Im regulierten Umfeld entsteht dadurch aber noch keine vollständige Nachweisführung.

Ein Ticket kann erledigt sein. Eine User Story kann abgeschlossen sein. Ein Inkrement kann geliefert sein. Trotzdem kann offen bleiben, ob der fachliche Ursprung, die Entscheidung, der Test, die Abnahme und der Produktionsnachweis belastbar miteinander verbunden sind.

Genau dort entstehen Risiken.

Nicht, weil agil gearbeitet wird. Sondern weil Anforderungen oft nicht als durchgängiger fachlicher Nachweis geführt werden.

Nachträgliche Dokumentation

Was erst am Ende dokumentiert wird, ist oft nur noch Rekonstruktion.

In vielen Projekten entsteht Dokumentation spät.

Kurz vor Abnahme, Audit, Go-Live oder Revision wird versucht, nachträglich zusammenzuführen, was im Projektverlauf nicht sauber verbunden wurde.

Dann werden Tickets gesucht, Entscheidungen rekonstruiert, Testnachweise zusammengesammelt, Abnahmen nachgetragen und Produktionsstände erklärt.

Das ist kein belastbares Anforderungsmanagement. Das ist nachträgliche Spurensuche.

MORe setzt früher an.

Die Dokumentation entsteht dort, wo die Arbeit an der Anforderung stattfindet. Nicht als zusätzliche Bürokratie, sondern als Bestandteil der fachlichen Klärung, Entscheidung, Umsetzung, Prüfung und Abnahme.

Tooling

Ein Werkzeug kann Verknüpfungen speichern. Es ersetzt keine fachliche Verantwortung.

Jira, Confluence, Azure DevOps, Polarion, DOORS oder andere Werkzeuge können Anforderungen, Tickets, Dokumente, Tests und Nachweise verwalten.

Sie können Felder bereitstellen, Links speichern, Workflows abbilden und Reports erzeugen.

Was sie nicht automatisch leisten: fachliche Klarheit.

Ein Tool entscheidet nicht, ob eine Anforderung vollständig verstanden wurde. Es bewertet nicht, ob eine Abnahme fachlich belastbar ist. Es erkennt nicht von selbst, ob regulatorische Relevanz besteht. Es stellt auch nicht sicher, dass die Verbindung zwischen Anforderung, Test, Abnahme und Produktion inhaltlich sinnvoll ist.

MORe ist deshalb kein Toolersatz.

MORe ist die fachliche Struktur, die ein Werkzeug erst sinnvoll nutzbar macht.

User Stories

User Stories beschreiben Bedarf. Im regulierten Umfeld reicht das allein nicht.

User Stories sind hilfreich, um Anforderungen aus Nutzersicht zu formulieren.

Sie beantworten aber nicht automatisch alle Fragen, die im regulierten Umfeld relevant sind.

Zum Beispiel:

  • Welche fachliche Entscheidung liegt der Anforderung zugrunde?
  • Welche regulatorische oder organisatorische Relevanz besteht?
  • Welche Auswirkungen hat die Änderung auf Prozesse, Daten, Schnittstellen oder Kontrollen?
  • Welche Akzeptanzkriterien sind prüfbar?
  • Welche Tests decken die Anforderung ab?
  • Wer nimmt die Umsetzung fachlich ab?
  • Wie wird der produktive Einsatz nachgewiesen?

MORe erweitert die Arbeit an Anforderungen um genau diese Perspektive.

Nicht gegen User Stories. Sondern dort, wo User Stories allein nicht ausreichen.

Kernunterschied

MORe führt Anforderungen nicht nur bis zur Umsetzung, sondern bis zum Nachweis.

Viele Vorgehensmodelle konzentrieren sich auf Lieferung.

MOR*e" konzentriert sich zusätzlich auf Nachvollziehbarkeit.

Eine Anforderung ist nicht nur dann relevant, wenn sie geplant, umgesetzt oder getestet wird. Sie bleibt relevant, bis nachvollziehbar ist, dass sie fachlich entschieden, korrekt umgesetzt, geprüft, abgenommen und produktiv wirksam wurde.

Der Lebenszyklus endet deshalb nicht beim Ticketstatus „Done“.

Er endet erst dort, wo der fachliche und produktive Nachweis belastbar geführt ist.

Das ist der Unterschied zwischen erledigter Arbeit und nachweisbarer Arbeit.

Regulierung

Regulierung verlangt keine Papierberge. Sie verlangt belastbare Nachvollziehbarkeit.

Regulierte Umfelder werden häufig mit zusätzlicher Bürokratie verwechselt.

MORe verfolgt einen anderen Ansatz.

Es geht nicht darum, mehr Dokumente zu erzeugen. Es geht darum, die ohnehin notwendige Arbeit an Anforderungen so zu strukturieren, dass Nachvollziehbarkeit entsteht.

Was fachlich geklärt werden muss, wird dokumentiert.

Was entschieden werden muss, wird nachvollziehbar festgehalten.

Was getestet und abgenommen werden muss, wird mit der Anforderung verbunden.

Was produktiv geht, bleibt rückverfolgbar.

So entsteht Nachweisfähigkeit nicht als Zusatzaufwand am Ende, sondern als Bestandteil sauberer Arbeit.

Einordnung

MORe ersetzt keine bestehenden Frameworks. MORe ergänzt sie.

MORe ist kein Ersatz für Scrum, Kanban, LeSS, SAFe, klassische Projektsteuerung oder Requirements Engineering.

Diese Ansätze beantworten wichtige Fragen:

  • Wie organisieren Teams ihre Arbeit?
  • Wie werden Prioritäten gesetzt?
  • Wie wird geliefert?
  • Wie wird Zusammenarbeit strukturiert?
  • Wie wird Skalierung organisiert?

MORe beantwortet eine andere Frage:

Wie bleiben Anforderungen von der fachlichen Idee bis zur Produktion nachvollziehbar?

Damit kann MORe in agilen, hybriden und klassischen Umfeldern eingesetzt werden.

Es ergänzt bestehende Arbeitsmodelle um die Perspektive der regulatorischen Nachweisfähigkeit.

Nutzen

MORe reduziert Blindflug in der Anforderungsarbeit.

MOR*e" schafft Klarheit darüber, wo Anforderungen stehen und welche Nachweise noch fehlen.

Das hilft unterschiedlichen Rollen:

Projektleitungen erkennen Risiken früher.

Product Owner und Business Owner behalten den fachlichen Zusammenhang im Blick.

Business Analysten und Requirements Engineers arbeiten mit klareren Strukturen.

Testmanager sehen, welche Anforderungen durch welche Tests abgedeckt sind.

Revision, Compliance und Audit erhalten nachvollziehbare Nachweise.

IT- und Fachbereichsleitung können Entscheidungen besser einordnen.

MORe macht nicht jedes Projekt einfacher. Aber es macht sichtbar, wo Nachvollziehbarkeit fehlt.

Kurz gesagt

MORE macht Anforderungen prüfbar nachvollziehbar.

MORe steht für ein einfaches Prinzip:

Anforderungen werden nicht erst am Ende dokumentiert.

Sie werden während ihrer Bearbeitung so geführt, dass fachliche Entscheidung, Umsetzung, Test, Abnahme und Produktion nachvollziehbar verbunden bleiben.

Das Ziel ist nicht mehr Bürokratie.

Das Ziel ist weniger Rekonstruktion.

More traceability.
Less reconstruction.