
Gewerblich
Die absolut größte Veränderung, die über den Erfolg oder Misserfolg einer Ausschreibung entscheidet
Die absolut größte Veränderung, die über den Erfolg oder Misserfolg einer Ausschreibung entscheidet
Die absolut größte Veränderung, die über den Erfolg oder Misserfolg einer Ausschreibung entscheidet
Die eine, größte Veränderung, die über Erfolg oder Misserfolg einer Ausschreibung (RFP) entscheidet
Die meisten RFPs scheitern aus vielen Gründen.
Sie verzögern sich, verbrauchen mehr interne Ressourcen als geplant, Anbieter versprechen zu viel, die Leistung bleibt hinter den Erwartungen zurück und kommerzielle Diskussionen nehmen bereits wenige Monate nach Vertragsunterzeichnung einen konfrontativen Charakter an.
Doch nach unserer Erfahrung in Medien-, OTT-, Rundfunk- und Digital-Publishing-Unternehmen scheitern RFPs fast immer an derselben Stelle – lange bevor Anbieter ausgewählt werden und oft sogar noch bevor das Dokument überhaupt veröffentlicht wird.
Sie scheitern an der Art und Weise, wie die Anforderungen formuliert sind.
Wenn es eine einzige Änderung gibt, die der Verfasser einer Ausschreibung vornehmen kann und die einen überproportionalen Einfluss auf das Ergebnis hat, dann ist es diese:
Hören Sie auf, Anbieter zu bitten, Fähigkeiten zu beschreiben, und zwingen Sie sie stattdessen, diese durch klare, eindeutige und messbare Anforderungen nachzuweisen.
Alles andere im RFP-Prozess ist zweitrangig.
Warum sich RFPs fair anfühlen, aber zu schlechten Entscheidungen führen
Die meisten schlecht performenden RFPs wirken oberflächlich betrachtet nicht fehlerhaft. Tatsächlich erscheinen sie oft gründlich, strukturiert und vernünftig.
Sie enthalten sinnvolle Fragen wie:
Beschreiben Sie Ihre Suchfunktion innerhalb des CMS
Erklären Sie, wie Ihre Plattform die Lokalisierung unterstützt
Erzählen Sie uns von Ihrem Ansatz zur Skalierbarkeit und Leistung
Diese Fragen fühlen sich offen, partnerschaftlich und anbieterfreundlich an. Sie wirken auch informativ.
In der Praxis führen sie jedoch zu drei systemischen Problemen.
Erstens laden sie zur Interpretation ein. Jeder Anbieter beantwortet eine subtly andere Frage.
Zweitens belohnen sie Marketingstärke anstelle von tatsächlicher Produktwahrheit. Narrative Antworten klingen überzeugend, selbst wenn eine Funktion nur lückenhaft vorhanden, auf der Roadmap geplant oder bloß angenommen ist.
Drittens machen sie einen objektiven Vergleich unmöglich. Bewertungsdiskussionen driften schnell von Beweisen zu Meinungen ab, und die Punktevergabe wird eher zu einer Übung in Überzeugungskraft als zu einer echten Bewertung.
An diesem Punkt ist der RFP-Prozess bereits kompromittiert – selbst wenn jeder andere Schritt perfekt ausgeführt wird.
Der Moment, in dem alles schiefgeht: Subjektive Anforderungen
Das häufigste Fehlermuster, das wir beobachten, beginnt mit einem einzigen Wort:
„Beschreiben.“
Zum Beispiel:
„Beschreiben Sie die Suchfunktion im CMS.“
Diese Anforderung kann nicht objektiv bewertet werden. Es gibt keine gemeinsame Definition von Erfolg, keinen messbaren Schwellenwert und keine Möglichkeit, die Konformität mit Gewissheit festzustellen.
Jeder Anbieter kann positiv antworten, ohne sich auf etwas Überprüfbares festlegen zu müssen.
Was folgt, ist vorhersehbar:
Prüfer füllen Lücken mit Annahmen
Workshops werden genutzt, um grundlegende Funktionen zu klären
Vertragsverhandlungen versuchen nachträglich, den Leistungsumfang festzulegen
Die Bereitstellung offenbart nicht übereinstimmende Erwartungen
Das RFP scheiterte nicht, weil die Anbieter unehrlich waren. Es scheiterte, weil die Anforderungen es ihnen erlaubten, vage zu bleiben.
Was hervorragende RFP-Verfasser anders machen
Starke RFP-Verfasser gehen ganz anders an Anforderungen heran.
Anstatt Anbieter zu fragen, wie etwas funktioniert, definieren sie zu Beginn, was erfüllt sein muss, damit die Lösung akzeptabel ist.
Sie nehmen einen übergeordneten Produktbedarf oder eine User Story und zerlegen diese in eine Reihe von atomaren, testbaren Aussagen.
Jede Aussage ist:
Klar
Eindeutig
Messbar
Unabhängig bewertbar
Entscheidend ist, dass jede Aussage nur eine von zwei Antworten zulässt: Wahr oder Falsch.
Beispielsweise, anstatt nach der Suchfunktion zu fragen:
Die Lösung MUSS die Suche über alle im CMS gespeicherten Metadatenattribute für jedes beliebige Objekt unterstützen.
Die Lösung MUSS die Suche in allen Sprachen unterstützen, die innerhalb eines mehrsprachigen Artikels definiert sind.
Die Lösung MUSS unter normalen Betriebsbedingungen Suchergebnisse innerhalb von zwei Sekunden für Datenbestände von bis zu X Millionen Objekten liefern. (Und vergessen Sie nicht zu definieren, was normale Betriebsbedingungen sind!)
Es gibt keinen Interpretationsspielraum. Entweder ist die Funktion vorhanden oder nicht.
Dieser Ansatz verändert die Natur der Ausschreibung grundlegend.
Warum binäre Anforderungen die Ergebnisse transformieren
Wenn Anforderungen als objektive Aussagen und nicht als narrative Aufforderungen formuliert werden, passieren sofort mehrere Dinge.
Die Antworten der Anbieter werden kürzer und präziser. Marketingsprache verschwindet, da sie nicht mehr hilfreich ist.
Funktionslücken treten frühzeitig zutage. Anbieter sind gezwungen, Einschränkungen, Abhängigkeiten oder Roadmap-Elemente explizit offenzulegen.
Die Bewertung wird schneller und nachvollziehbarer. Bewertungsdiskussionen basieren auf Beweisen statt auf Meinungen.
In Workshops geht es um Validierung und Tiefe, nicht um grundlegende Klärungen.
Vor allem aber lassen sich Verträge leichter verhandeln. Die Anforderungsmatrix definiert bereits die akzeptable Mindestfunktionalität, was Unklarheiten und das Risiko von Streitigkeiten verringert.
Dies ist der effektivste Weg, um nachträgliche Änderungsanträge, kommerzielle Reibungsverluste und Enttäuschungen bei der Umsetzung zu reduzieren.
User Stories in Anforderungen übersetzen, ohne die Zukunft zu verbauen
Eine der häufigsten Sorgen bei der Formulierung hochspezifischer, messbarer Anforderungen ist, dass sie die Lösung zu stark einschränken.
Diese Sorge ist berechtigt – aber sie ist kein Grund, vage Anforderungen zu akzeptieren. Sie ist ein Signal dafür, dass Anforderungen mit Bedacht formuliert werden müssen.
Spezifische und objektive Anforderungen sollten nicht beschreiben, wie eine Lösung aufgebaut ist. Sie sollten das Verhalten definieren, das gegeben sein muss, während sie gleichzeitig bewusst Raum für Weiterentwicklung, Rekonfiguration und zukünftige Änderungen lassen.
Diese Unterscheidung ist entscheidend.
Schlecht geschriebene Anforderungen zementieren die Annahmen von heute:
Sie schreiben interne Architekturen vor
Sie fordern bestimmte Implementierungsmuster
Sie verankern aktuelle organisatorische Einschränkungen als dauerhafte Wahrheiten
Gut geschriebene Anforderungen tun das Gegenteil. Sie definieren Ergebnisse, die einen „Architect-for-Change“-Ansatz unterstützen.
Zum Beispiel:
Anstatt:
Die Lösung MUSS Technologie X verwenden, um die mehrsprachige Suche zu unterstützen.
Bevorzugen Sie:
Die Lösung MUSS die Suche in allen innerhalb eines mehrsprachigen Artikels definierten Sprachen unterstützen, ohne dass für jede zusätzliche Sprache eine individuelle Entwicklung erforderlich ist.
Anstatt:
Das CMS MUSS mit einem festen Inhaltsmodell konfiguriert werden, das bei der Implementierung definiert wird.
Bevorzugen Sie:
Das CMS MUSS es autorisierten Benutzern ermöglichen, Inhaltsmodelle ohne Codeänderungen oder erneute Bereitstellung der Plattform zu erweitern und zu ändern.
In beiden Fällen ist die Anforderung immer noch binär und testbar, aber sie bewahrt die Flexibilität zur Anpassung.
So werden zukünftige Änderungen verantwortungsvoll gemanagt. Sie sagen nicht voraus, was die Plattform einmal werden muss. Sie stellen lediglich sicher, dass sie sich verändern kann, wenn sich das Geschäft unweigerlich weiterentwickelt.
Übergeordnete User Stories spielen nach wie vor eine wichtige Rolle. Sie drücken Absicht und Richtung aus. Der Bewertungsmechanismus bleibt jedoch der Anforderungskatalog, der darauf ausgelegt ist, funktionale Fähigkeiten zu testen, und nicht Designvorlieben.
Diese Balance ist schwer zu erreichen. Es erfordert Erfahrung, um zu wissen, welche Einschränkungen das Unternehmen schützen und welche lediglich das aktuelle Denken konservieren.
Dieses Urteilsvermögen macht den Unterschied aus zwischen Anforderungen, die gut altern, und solchen, die bereits vor der Vertragsunterzeichnung veraltet sind.
Warum das Schreiben großartiger Anforderungen wirklich schwer ist
Es gibt einen Grund, warum dieser Ansatz selten gut umgesetzt wird.
Das Formulieren von Anforderungen, die spezifisch, klar, messbar und objektiv sind, ist keine rein administrative Aufgabe. Es ist eine analytische Disziplin an der Schnittstelle von Produktdenken, Systemtechnik, operativer Realität und kommerziellem Risiko.
In den meisten Unternehmen sehen wir schlichtweg nicht viele Menschen, die dies konstant leisten können.
Aus diesem Grund ziehen Unternehmen, die komplexe Medien- und Plattformprogramme durchführen, oft spezialisierte Experten für Ausschreibungen und RFPs hinzu, wenn die Entscheidung langfristige Risiken birgt.
Verfasser von Anforderungen müssen in der Lage sein:
Nutzerbedürfnisse zu verstehen, ohne User Stories wortwörtlich zu kopieren
Abstrakte Geschäftsziele in konkretes Systemverhalten zu übersetzen
Skalierung, Grenzfälle und Fehlerszenarien vorzusehen
Unklarheiten zu beseitigen, ohne die Umsetzung zu stark einzuschränken
Aussagen zu formulieren, die testbar, vertretbar und vertragsreif sind
Diese Kombination von Fähigkeiten ist selten. Infolgedessen werden Anforderungen oft von Ausschüssen verfasst, durch Kompromisse verwässert oder an Teams delegiert, denen die nötige Erfahrung fehlt. Das Ergebnis ist vorhersehbar: gut gemeinte Dokumente, die das Unternehmen letztlich nicht schützen.
Dies ist auch der Grund, warum strenge Anforderungen intern oft als unangenehm empfunden werden. Sie erzwingen Entscheidungen früher, als es viele Organisationen gewohnt sind. Sie legen Unsicherheiten offen. Sie nehmen die Komfortzone vager Formulierungen weg.
Warum alles andere immer noch wichtig ist … nur nicht so sehr
Zeitpläne sind wichtig. Governance ist wichtig. Kommunikation ist wichtig. Fairness ist wichtig.
Aber nichts davon kann schwache Anforderungen kompensieren.
Ein perfekt durchgeführter RFP-Prozess, der auf unklaren Anforderungen basiert, wird dennoch zu einem schlechten Ergebnis führen. Ein weniger eleganter Prozess, der auf präzisen, objektiven Anforderungen aufbaut, ist trotz Mängeln an anderer Stelle oft erfolgreich.
Diese Hierarchie ist unbequem, insbesondere in einkaufsorientierten Umgebungen. Aber sie spiegelt die Realität wider.
Wenn Sie eine Sache ändern, dann diese
Wenn Sie kurz davor stehen, eine Ausschreibung zu veröffentlichen, überprüfen Sie sie mit einer Frage im Hinterkopf:
Kann jede Anforderung ohne Diskussion objektiv bewertet werden?
Wenn die Antwort „Nein“ lautet, sollten Sie genau dort Ihre Arbeit ansetzen.
Dies richtig zu machen, erfordert Zeit und Disziplin. Es erfordert, vagen Formulierungen zu widerstehen und früher für Klarheit zu sorgen, als es sich bequem anfühlt.
Der Nutzen ist beträchtlich.
Spicy Mango verfügt über umfangreiche RFP-Frameworks und Anforderungsbibliotheken für OTT-, Streaming- und Digital-Publishing-Plattformen, die auf realer Projekterfahrung basieren. Wir lizenzieren Referenzmaterial, das Hunderte von übergeordneten funktionalen und nicht-funktionalen Anforderungen in Tausende von präzisen, klaren und messbaren Aussagen übersetzt hat. Diese Tiefe ist einer der Gründe, warum namhafte Medienunternehmen uns mit der Gestaltung und Umsetzung strategischer Transformationsprogramme beauftragen – nicht nur, um den Einkauf zu steuern, sondern um auf Anforderungsebene zu definieren, wie Erfolg tatsächlich aussieht. Wenn Sie diese Arbeit beschleunigen möchten, ohne an Gründlichkeit einzubüßen, kontaktieren Sie uns, um zu sehen, wie eine exzellente Umsetzung in der Praxis aussieht.
Die eine, größte Veränderung, die über Erfolg oder Misserfolg einer Ausschreibung (RFP) entscheidet
Die meisten RFPs scheitern aus vielen Gründen.
Sie verzögern sich, verbrauchen mehr interne Ressourcen als geplant, Anbieter versprechen zu viel, die Leistung bleibt hinter den Erwartungen zurück und kommerzielle Diskussionen nehmen bereits wenige Monate nach Vertragsunterzeichnung einen konfrontativen Charakter an.
Doch nach unserer Erfahrung in Medien-, OTT-, Rundfunk- und Digital-Publishing-Unternehmen scheitern RFPs fast immer an derselben Stelle – lange bevor Anbieter ausgewählt werden und oft sogar noch bevor das Dokument überhaupt veröffentlicht wird.
Sie scheitern an der Art und Weise, wie die Anforderungen formuliert sind.
Wenn es eine einzige Änderung gibt, die der Verfasser einer Ausschreibung vornehmen kann und die einen überproportionalen Einfluss auf das Ergebnis hat, dann ist es diese:
Hören Sie auf, Anbieter zu bitten, Fähigkeiten zu beschreiben, und zwingen Sie sie stattdessen, diese durch klare, eindeutige und messbare Anforderungen nachzuweisen.
Alles andere im RFP-Prozess ist zweitrangig.
Warum sich RFPs fair anfühlen, aber zu schlechten Entscheidungen führen
Die meisten schlecht performenden RFPs wirken oberflächlich betrachtet nicht fehlerhaft. Tatsächlich erscheinen sie oft gründlich, strukturiert und vernünftig.
Sie enthalten sinnvolle Fragen wie:
Beschreiben Sie Ihre Suchfunktion innerhalb des CMS
Erklären Sie, wie Ihre Plattform die Lokalisierung unterstützt
Erzählen Sie uns von Ihrem Ansatz zur Skalierbarkeit und Leistung
Diese Fragen fühlen sich offen, partnerschaftlich und anbieterfreundlich an. Sie wirken auch informativ.
In der Praxis führen sie jedoch zu drei systemischen Problemen.
Erstens laden sie zur Interpretation ein. Jeder Anbieter beantwortet eine subtly andere Frage.
Zweitens belohnen sie Marketingstärke anstelle von tatsächlicher Produktwahrheit. Narrative Antworten klingen überzeugend, selbst wenn eine Funktion nur lückenhaft vorhanden, auf der Roadmap geplant oder bloß angenommen ist.
Drittens machen sie einen objektiven Vergleich unmöglich. Bewertungsdiskussionen driften schnell von Beweisen zu Meinungen ab, und die Punktevergabe wird eher zu einer Übung in Überzeugungskraft als zu einer echten Bewertung.
An diesem Punkt ist der RFP-Prozess bereits kompromittiert – selbst wenn jeder andere Schritt perfekt ausgeführt wird.
Der Moment, in dem alles schiefgeht: Subjektive Anforderungen
Das häufigste Fehlermuster, das wir beobachten, beginnt mit einem einzigen Wort:
„Beschreiben.“
Zum Beispiel:
„Beschreiben Sie die Suchfunktion im CMS.“
Diese Anforderung kann nicht objektiv bewertet werden. Es gibt keine gemeinsame Definition von Erfolg, keinen messbaren Schwellenwert und keine Möglichkeit, die Konformität mit Gewissheit festzustellen.
Jeder Anbieter kann positiv antworten, ohne sich auf etwas Überprüfbares festlegen zu müssen.
Was folgt, ist vorhersehbar:
Prüfer füllen Lücken mit Annahmen
Workshops werden genutzt, um grundlegende Funktionen zu klären
Vertragsverhandlungen versuchen nachträglich, den Leistungsumfang festzulegen
Die Bereitstellung offenbart nicht übereinstimmende Erwartungen
Das RFP scheiterte nicht, weil die Anbieter unehrlich waren. Es scheiterte, weil die Anforderungen es ihnen erlaubten, vage zu bleiben.
Was hervorragende RFP-Verfasser anders machen
Starke RFP-Verfasser gehen ganz anders an Anforderungen heran.
Anstatt Anbieter zu fragen, wie etwas funktioniert, definieren sie zu Beginn, was erfüllt sein muss, damit die Lösung akzeptabel ist.
Sie nehmen einen übergeordneten Produktbedarf oder eine User Story und zerlegen diese in eine Reihe von atomaren, testbaren Aussagen.
Jede Aussage ist:
Klar
Eindeutig
Messbar
Unabhängig bewertbar
Entscheidend ist, dass jede Aussage nur eine von zwei Antworten zulässt: Wahr oder Falsch.
Beispielsweise, anstatt nach der Suchfunktion zu fragen:
Die Lösung MUSS die Suche über alle im CMS gespeicherten Metadatenattribute für jedes beliebige Objekt unterstützen.
Die Lösung MUSS die Suche in allen Sprachen unterstützen, die innerhalb eines mehrsprachigen Artikels definiert sind.
Die Lösung MUSS unter normalen Betriebsbedingungen Suchergebnisse innerhalb von zwei Sekunden für Datenbestände von bis zu X Millionen Objekten liefern. (Und vergessen Sie nicht zu definieren, was normale Betriebsbedingungen sind!)
Es gibt keinen Interpretationsspielraum. Entweder ist die Funktion vorhanden oder nicht.
Dieser Ansatz verändert die Natur der Ausschreibung grundlegend.
Warum binäre Anforderungen die Ergebnisse transformieren
Wenn Anforderungen als objektive Aussagen und nicht als narrative Aufforderungen formuliert werden, passieren sofort mehrere Dinge.
Die Antworten der Anbieter werden kürzer und präziser. Marketingsprache verschwindet, da sie nicht mehr hilfreich ist.
Funktionslücken treten frühzeitig zutage. Anbieter sind gezwungen, Einschränkungen, Abhängigkeiten oder Roadmap-Elemente explizit offenzulegen.
Die Bewertung wird schneller und nachvollziehbarer. Bewertungsdiskussionen basieren auf Beweisen statt auf Meinungen.
In Workshops geht es um Validierung und Tiefe, nicht um grundlegende Klärungen.
Vor allem aber lassen sich Verträge leichter verhandeln. Die Anforderungsmatrix definiert bereits die akzeptable Mindestfunktionalität, was Unklarheiten und das Risiko von Streitigkeiten verringert.
Dies ist der effektivste Weg, um nachträgliche Änderungsanträge, kommerzielle Reibungsverluste und Enttäuschungen bei der Umsetzung zu reduzieren.
User Stories in Anforderungen übersetzen, ohne die Zukunft zu verbauen
Eine der häufigsten Sorgen bei der Formulierung hochspezifischer, messbarer Anforderungen ist, dass sie die Lösung zu stark einschränken.
Diese Sorge ist berechtigt – aber sie ist kein Grund, vage Anforderungen zu akzeptieren. Sie ist ein Signal dafür, dass Anforderungen mit Bedacht formuliert werden müssen.
Spezifische und objektive Anforderungen sollten nicht beschreiben, wie eine Lösung aufgebaut ist. Sie sollten das Verhalten definieren, das gegeben sein muss, während sie gleichzeitig bewusst Raum für Weiterentwicklung, Rekonfiguration und zukünftige Änderungen lassen.
Diese Unterscheidung ist entscheidend.
Schlecht geschriebene Anforderungen zementieren die Annahmen von heute:
Sie schreiben interne Architekturen vor
Sie fordern bestimmte Implementierungsmuster
Sie verankern aktuelle organisatorische Einschränkungen als dauerhafte Wahrheiten
Gut geschriebene Anforderungen tun das Gegenteil. Sie definieren Ergebnisse, die einen „Architect-for-Change“-Ansatz unterstützen.
Zum Beispiel:
Anstatt:
Die Lösung MUSS Technologie X verwenden, um die mehrsprachige Suche zu unterstützen.
Bevorzugen Sie:
Die Lösung MUSS die Suche in allen innerhalb eines mehrsprachigen Artikels definierten Sprachen unterstützen, ohne dass für jede zusätzliche Sprache eine individuelle Entwicklung erforderlich ist.
Anstatt:
Das CMS MUSS mit einem festen Inhaltsmodell konfiguriert werden, das bei der Implementierung definiert wird.
Bevorzugen Sie:
Das CMS MUSS es autorisierten Benutzern ermöglichen, Inhaltsmodelle ohne Codeänderungen oder erneute Bereitstellung der Plattform zu erweitern und zu ändern.
In beiden Fällen ist die Anforderung immer noch binär und testbar, aber sie bewahrt die Flexibilität zur Anpassung.
So werden zukünftige Änderungen verantwortungsvoll gemanagt. Sie sagen nicht voraus, was die Plattform einmal werden muss. Sie stellen lediglich sicher, dass sie sich verändern kann, wenn sich das Geschäft unweigerlich weiterentwickelt.
Übergeordnete User Stories spielen nach wie vor eine wichtige Rolle. Sie drücken Absicht und Richtung aus. Der Bewertungsmechanismus bleibt jedoch der Anforderungskatalog, der darauf ausgelegt ist, funktionale Fähigkeiten zu testen, und nicht Designvorlieben.
Diese Balance ist schwer zu erreichen. Es erfordert Erfahrung, um zu wissen, welche Einschränkungen das Unternehmen schützen und welche lediglich das aktuelle Denken konservieren.
Dieses Urteilsvermögen macht den Unterschied aus zwischen Anforderungen, die gut altern, und solchen, die bereits vor der Vertragsunterzeichnung veraltet sind.
Warum das Schreiben großartiger Anforderungen wirklich schwer ist
Es gibt einen Grund, warum dieser Ansatz selten gut umgesetzt wird.
Das Formulieren von Anforderungen, die spezifisch, klar, messbar und objektiv sind, ist keine rein administrative Aufgabe. Es ist eine analytische Disziplin an der Schnittstelle von Produktdenken, Systemtechnik, operativer Realität und kommerziellem Risiko.
In den meisten Unternehmen sehen wir schlichtweg nicht viele Menschen, die dies konstant leisten können.
Aus diesem Grund ziehen Unternehmen, die komplexe Medien- und Plattformprogramme durchführen, oft spezialisierte Experten für Ausschreibungen und RFPs hinzu, wenn die Entscheidung langfristige Risiken birgt.
Verfasser von Anforderungen müssen in der Lage sein:
Nutzerbedürfnisse zu verstehen, ohne User Stories wortwörtlich zu kopieren
Abstrakte Geschäftsziele in konkretes Systemverhalten zu übersetzen
Skalierung, Grenzfälle und Fehlerszenarien vorzusehen
Unklarheiten zu beseitigen, ohne die Umsetzung zu stark einzuschränken
Aussagen zu formulieren, die testbar, vertretbar und vertragsreif sind
Diese Kombination von Fähigkeiten ist selten. Infolgedessen werden Anforderungen oft von Ausschüssen verfasst, durch Kompromisse verwässert oder an Teams delegiert, denen die nötige Erfahrung fehlt. Das Ergebnis ist vorhersehbar: gut gemeinte Dokumente, die das Unternehmen letztlich nicht schützen.
Dies ist auch der Grund, warum strenge Anforderungen intern oft als unangenehm empfunden werden. Sie erzwingen Entscheidungen früher, als es viele Organisationen gewohnt sind. Sie legen Unsicherheiten offen. Sie nehmen die Komfortzone vager Formulierungen weg.
Warum alles andere immer noch wichtig ist … nur nicht so sehr
Zeitpläne sind wichtig. Governance ist wichtig. Kommunikation ist wichtig. Fairness ist wichtig.
Aber nichts davon kann schwache Anforderungen kompensieren.
Ein perfekt durchgeführter RFP-Prozess, der auf unklaren Anforderungen basiert, wird dennoch zu einem schlechten Ergebnis führen. Ein weniger eleganter Prozess, der auf präzisen, objektiven Anforderungen aufbaut, ist trotz Mängeln an anderer Stelle oft erfolgreich.
Diese Hierarchie ist unbequem, insbesondere in einkaufsorientierten Umgebungen. Aber sie spiegelt die Realität wider.
Wenn Sie eine Sache ändern, dann diese
Wenn Sie kurz davor stehen, eine Ausschreibung zu veröffentlichen, überprüfen Sie sie mit einer Frage im Hinterkopf:
Kann jede Anforderung ohne Diskussion objektiv bewertet werden?
Wenn die Antwort „Nein“ lautet, sollten Sie genau dort Ihre Arbeit ansetzen.
Dies richtig zu machen, erfordert Zeit und Disziplin. Es erfordert, vagen Formulierungen zu widerstehen und früher für Klarheit zu sorgen, als es sich bequem anfühlt.
Der Nutzen ist beträchtlich.
Spicy Mango verfügt über umfangreiche RFP-Frameworks und Anforderungsbibliotheken für OTT-, Streaming- und Digital-Publishing-Plattformen, die auf realer Projekterfahrung basieren. Wir lizenzieren Referenzmaterial, das Hunderte von übergeordneten funktionalen und nicht-funktionalen Anforderungen in Tausende von präzisen, klaren und messbaren Aussagen übersetzt hat. Diese Tiefe ist einer der Gründe, warum namhafte Medienunternehmen uns mit der Gestaltung und Umsetzung strategischer Transformationsprogramme beauftragen – nicht nur, um den Einkauf zu steuern, sondern um auf Anforderungsebene zu definieren, wie Erfolg tatsächlich aussieht. Wenn Sie diese Arbeit beschleunigen möchten, ohne an Gründlichkeit einzubüßen, kontaktieren Sie uns, um zu sehen, wie eine exzellente Umsetzung in der Praxis aussieht.
Die eine, größte Veränderung, die über Erfolg oder Misserfolg einer Ausschreibung (RFP) entscheidet
Die meisten RFPs scheitern aus vielen Gründen.
Sie verzögern sich, verbrauchen mehr interne Ressourcen als geplant, Anbieter versprechen zu viel, die Leistung bleibt hinter den Erwartungen zurück und kommerzielle Diskussionen nehmen bereits wenige Monate nach Vertragsunterzeichnung einen konfrontativen Charakter an.
Doch nach unserer Erfahrung in Medien-, OTT-, Rundfunk- und Digital-Publishing-Unternehmen scheitern RFPs fast immer an derselben Stelle – lange bevor Anbieter ausgewählt werden und oft sogar noch bevor das Dokument überhaupt veröffentlicht wird.
Sie scheitern an der Art und Weise, wie die Anforderungen formuliert sind.
Wenn es eine einzige Änderung gibt, die der Verfasser einer Ausschreibung vornehmen kann und die einen überproportionalen Einfluss auf das Ergebnis hat, dann ist es diese:
Hören Sie auf, Anbieter zu bitten, Fähigkeiten zu beschreiben, und zwingen Sie sie stattdessen, diese durch klare, eindeutige und messbare Anforderungen nachzuweisen.
Alles andere im RFP-Prozess ist zweitrangig.
Warum sich RFPs fair anfühlen, aber zu schlechten Entscheidungen führen
Die meisten schlecht performenden RFPs wirken oberflächlich betrachtet nicht fehlerhaft. Tatsächlich erscheinen sie oft gründlich, strukturiert und vernünftig.
Sie enthalten sinnvolle Fragen wie:
Beschreiben Sie Ihre Suchfunktion innerhalb des CMS
Erklären Sie, wie Ihre Plattform die Lokalisierung unterstützt
Erzählen Sie uns von Ihrem Ansatz zur Skalierbarkeit und Leistung
Diese Fragen fühlen sich offen, partnerschaftlich und anbieterfreundlich an. Sie wirken auch informativ.
In der Praxis führen sie jedoch zu drei systemischen Problemen.
Erstens laden sie zur Interpretation ein. Jeder Anbieter beantwortet eine subtly andere Frage.
Zweitens belohnen sie Marketingstärke anstelle von tatsächlicher Produktwahrheit. Narrative Antworten klingen überzeugend, selbst wenn eine Funktion nur lückenhaft vorhanden, auf der Roadmap geplant oder bloß angenommen ist.
Drittens machen sie einen objektiven Vergleich unmöglich. Bewertungsdiskussionen driften schnell von Beweisen zu Meinungen ab, und die Punktevergabe wird eher zu einer Übung in Überzeugungskraft als zu einer echten Bewertung.
An diesem Punkt ist der RFP-Prozess bereits kompromittiert – selbst wenn jeder andere Schritt perfekt ausgeführt wird.
Der Moment, in dem alles schiefgeht: Subjektive Anforderungen
Das häufigste Fehlermuster, das wir beobachten, beginnt mit einem einzigen Wort:
„Beschreiben.“
Zum Beispiel:
„Beschreiben Sie die Suchfunktion im CMS.“
Diese Anforderung kann nicht objektiv bewertet werden. Es gibt keine gemeinsame Definition von Erfolg, keinen messbaren Schwellenwert und keine Möglichkeit, die Konformität mit Gewissheit festzustellen.
Jeder Anbieter kann positiv antworten, ohne sich auf etwas Überprüfbares festlegen zu müssen.
Was folgt, ist vorhersehbar:
Prüfer füllen Lücken mit Annahmen
Workshops werden genutzt, um grundlegende Funktionen zu klären
Vertragsverhandlungen versuchen nachträglich, den Leistungsumfang festzulegen
Die Bereitstellung offenbart nicht übereinstimmende Erwartungen
Das RFP scheiterte nicht, weil die Anbieter unehrlich waren. Es scheiterte, weil die Anforderungen es ihnen erlaubten, vage zu bleiben.
Was hervorragende RFP-Verfasser anders machen
Starke RFP-Verfasser gehen ganz anders an Anforderungen heran.
Anstatt Anbieter zu fragen, wie etwas funktioniert, definieren sie zu Beginn, was erfüllt sein muss, damit die Lösung akzeptabel ist.
Sie nehmen einen übergeordneten Produktbedarf oder eine User Story und zerlegen diese in eine Reihe von atomaren, testbaren Aussagen.
Jede Aussage ist:
Klar
Eindeutig
Messbar
Unabhängig bewertbar
Entscheidend ist, dass jede Aussage nur eine von zwei Antworten zulässt: Wahr oder Falsch.
Beispielsweise, anstatt nach der Suchfunktion zu fragen:
Die Lösung MUSS die Suche über alle im CMS gespeicherten Metadatenattribute für jedes beliebige Objekt unterstützen.
Die Lösung MUSS die Suche in allen Sprachen unterstützen, die innerhalb eines mehrsprachigen Artikels definiert sind.
Die Lösung MUSS unter normalen Betriebsbedingungen Suchergebnisse innerhalb von zwei Sekunden für Datenbestände von bis zu X Millionen Objekten liefern. (Und vergessen Sie nicht zu definieren, was normale Betriebsbedingungen sind!)
Es gibt keinen Interpretationsspielraum. Entweder ist die Funktion vorhanden oder nicht.
Dieser Ansatz verändert die Natur der Ausschreibung grundlegend.
Warum binäre Anforderungen die Ergebnisse transformieren
Wenn Anforderungen als objektive Aussagen und nicht als narrative Aufforderungen formuliert werden, passieren sofort mehrere Dinge.
Die Antworten der Anbieter werden kürzer und präziser. Marketingsprache verschwindet, da sie nicht mehr hilfreich ist.
Funktionslücken treten frühzeitig zutage. Anbieter sind gezwungen, Einschränkungen, Abhängigkeiten oder Roadmap-Elemente explizit offenzulegen.
Die Bewertung wird schneller und nachvollziehbarer. Bewertungsdiskussionen basieren auf Beweisen statt auf Meinungen.
In Workshops geht es um Validierung und Tiefe, nicht um grundlegende Klärungen.
Vor allem aber lassen sich Verträge leichter verhandeln. Die Anforderungsmatrix definiert bereits die akzeptable Mindestfunktionalität, was Unklarheiten und das Risiko von Streitigkeiten verringert.
Dies ist der effektivste Weg, um nachträgliche Änderungsanträge, kommerzielle Reibungsverluste und Enttäuschungen bei der Umsetzung zu reduzieren.
User Stories in Anforderungen übersetzen, ohne die Zukunft zu verbauen
Eine der häufigsten Sorgen bei der Formulierung hochspezifischer, messbarer Anforderungen ist, dass sie die Lösung zu stark einschränken.
Diese Sorge ist berechtigt – aber sie ist kein Grund, vage Anforderungen zu akzeptieren. Sie ist ein Signal dafür, dass Anforderungen mit Bedacht formuliert werden müssen.
Spezifische und objektive Anforderungen sollten nicht beschreiben, wie eine Lösung aufgebaut ist. Sie sollten das Verhalten definieren, das gegeben sein muss, während sie gleichzeitig bewusst Raum für Weiterentwicklung, Rekonfiguration und zukünftige Änderungen lassen.
Diese Unterscheidung ist entscheidend.
Schlecht geschriebene Anforderungen zementieren die Annahmen von heute:
Sie schreiben interne Architekturen vor
Sie fordern bestimmte Implementierungsmuster
Sie verankern aktuelle organisatorische Einschränkungen als dauerhafte Wahrheiten
Gut geschriebene Anforderungen tun das Gegenteil. Sie definieren Ergebnisse, die einen „Architect-for-Change“-Ansatz unterstützen.
Zum Beispiel:
Anstatt:
Die Lösung MUSS Technologie X verwenden, um die mehrsprachige Suche zu unterstützen.
Bevorzugen Sie:
Die Lösung MUSS die Suche in allen innerhalb eines mehrsprachigen Artikels definierten Sprachen unterstützen, ohne dass für jede zusätzliche Sprache eine individuelle Entwicklung erforderlich ist.
Anstatt:
Das CMS MUSS mit einem festen Inhaltsmodell konfiguriert werden, das bei der Implementierung definiert wird.
Bevorzugen Sie:
Das CMS MUSS es autorisierten Benutzern ermöglichen, Inhaltsmodelle ohne Codeänderungen oder erneute Bereitstellung der Plattform zu erweitern und zu ändern.
In beiden Fällen ist die Anforderung immer noch binär und testbar, aber sie bewahrt die Flexibilität zur Anpassung.
So werden zukünftige Änderungen verantwortungsvoll gemanagt. Sie sagen nicht voraus, was die Plattform einmal werden muss. Sie stellen lediglich sicher, dass sie sich verändern kann, wenn sich das Geschäft unweigerlich weiterentwickelt.
Übergeordnete User Stories spielen nach wie vor eine wichtige Rolle. Sie drücken Absicht und Richtung aus. Der Bewertungsmechanismus bleibt jedoch der Anforderungskatalog, der darauf ausgelegt ist, funktionale Fähigkeiten zu testen, und nicht Designvorlieben.
Diese Balance ist schwer zu erreichen. Es erfordert Erfahrung, um zu wissen, welche Einschränkungen das Unternehmen schützen und welche lediglich das aktuelle Denken konservieren.
Dieses Urteilsvermögen macht den Unterschied aus zwischen Anforderungen, die gut altern, und solchen, die bereits vor der Vertragsunterzeichnung veraltet sind.
Warum das Schreiben großartiger Anforderungen wirklich schwer ist
Es gibt einen Grund, warum dieser Ansatz selten gut umgesetzt wird.
Das Formulieren von Anforderungen, die spezifisch, klar, messbar und objektiv sind, ist keine rein administrative Aufgabe. Es ist eine analytische Disziplin an der Schnittstelle von Produktdenken, Systemtechnik, operativer Realität und kommerziellem Risiko.
In den meisten Unternehmen sehen wir schlichtweg nicht viele Menschen, die dies konstant leisten können.
Aus diesem Grund ziehen Unternehmen, die komplexe Medien- und Plattformprogramme durchführen, oft spezialisierte Experten für Ausschreibungen und RFPs hinzu, wenn die Entscheidung langfristige Risiken birgt.
Verfasser von Anforderungen müssen in der Lage sein:
Nutzerbedürfnisse zu verstehen, ohne User Stories wortwörtlich zu kopieren
Abstrakte Geschäftsziele in konkretes Systemverhalten zu übersetzen
Skalierung, Grenzfälle und Fehlerszenarien vorzusehen
Unklarheiten zu beseitigen, ohne die Umsetzung zu stark einzuschränken
Aussagen zu formulieren, die testbar, vertretbar und vertragsreif sind
Diese Kombination von Fähigkeiten ist selten. Infolgedessen werden Anforderungen oft von Ausschüssen verfasst, durch Kompromisse verwässert oder an Teams delegiert, denen die nötige Erfahrung fehlt. Das Ergebnis ist vorhersehbar: gut gemeinte Dokumente, die das Unternehmen letztlich nicht schützen.
Dies ist auch der Grund, warum strenge Anforderungen intern oft als unangenehm empfunden werden. Sie erzwingen Entscheidungen früher, als es viele Organisationen gewohnt sind. Sie legen Unsicherheiten offen. Sie nehmen die Komfortzone vager Formulierungen weg.
Warum alles andere immer noch wichtig ist … nur nicht so sehr
Zeitpläne sind wichtig. Governance ist wichtig. Kommunikation ist wichtig. Fairness ist wichtig.
Aber nichts davon kann schwache Anforderungen kompensieren.
Ein perfekt durchgeführter RFP-Prozess, der auf unklaren Anforderungen basiert, wird dennoch zu einem schlechten Ergebnis führen. Ein weniger eleganter Prozess, der auf präzisen, objektiven Anforderungen aufbaut, ist trotz Mängeln an anderer Stelle oft erfolgreich.
Diese Hierarchie ist unbequem, insbesondere in einkaufsorientierten Umgebungen. Aber sie spiegelt die Realität wider.
Wenn Sie eine Sache ändern, dann diese
Wenn Sie kurz davor stehen, eine Ausschreibung zu veröffentlichen, überprüfen Sie sie mit einer Frage im Hinterkopf:
Kann jede Anforderung ohne Diskussion objektiv bewertet werden?
Wenn die Antwort „Nein“ lautet, sollten Sie genau dort Ihre Arbeit ansetzen.
Dies richtig zu machen, erfordert Zeit und Disziplin. Es erfordert, vagen Formulierungen zu widerstehen und früher für Klarheit zu sorgen, als es sich bequem anfühlt.
Der Nutzen ist beträchtlich.
Spicy Mango verfügt über umfangreiche RFP-Frameworks und Anforderungsbibliotheken für OTT-, Streaming- und Digital-Publishing-Plattformen, die auf realer Projekterfahrung basieren. Wir lizenzieren Referenzmaterial, das Hunderte von übergeordneten funktionalen und nicht-funktionalen Anforderungen in Tausende von präzisen, klaren und messbaren Aussagen übersetzt hat. Diese Tiefe ist einer der Gründe, warum namhafte Medienunternehmen uns mit der Gestaltung und Umsetzung strategischer Transformationsprogramme beauftragen – nicht nur, um den Einkauf zu steuern, sondern um auf Anforderungsebene zu definieren, wie Erfolg tatsächlich aussieht. Wenn Sie diese Arbeit beschleunigen möchten, ohne an Gründlichkeit einzubüßen, kontaktieren Sie uns, um zu sehen, wie eine exzellente Umsetzung in der Praxis aussieht.
Die eine, größte Veränderung, die über Erfolg oder Misserfolg einer Ausschreibung (RFP) entscheidet
Die meisten RFPs scheitern aus vielen Gründen.
Sie verzögern sich, verbrauchen mehr interne Ressourcen als geplant, Anbieter versprechen zu viel, die Leistung bleibt hinter den Erwartungen zurück und kommerzielle Diskussionen nehmen bereits wenige Monate nach Vertragsunterzeichnung einen konfrontativen Charakter an.
Doch nach unserer Erfahrung in Medien-, OTT-, Rundfunk- und Digital-Publishing-Unternehmen scheitern RFPs fast immer an derselben Stelle – lange bevor Anbieter ausgewählt werden und oft sogar noch bevor das Dokument überhaupt veröffentlicht wird.
Sie scheitern an der Art und Weise, wie die Anforderungen formuliert sind.
Wenn es eine einzige Änderung gibt, die der Verfasser einer Ausschreibung vornehmen kann und die einen überproportionalen Einfluss auf das Ergebnis hat, dann ist es diese:
Hören Sie auf, Anbieter zu bitten, Fähigkeiten zu beschreiben, und zwingen Sie sie stattdessen, diese durch klare, eindeutige und messbare Anforderungen nachzuweisen.
Alles andere im RFP-Prozess ist zweitrangig.
Warum sich RFPs fair anfühlen, aber zu schlechten Entscheidungen führen
Die meisten schlecht performenden RFPs wirken oberflächlich betrachtet nicht fehlerhaft. Tatsächlich erscheinen sie oft gründlich, strukturiert und vernünftig.
Sie enthalten sinnvolle Fragen wie:
Beschreiben Sie Ihre Suchfunktion innerhalb des CMS
Erklären Sie, wie Ihre Plattform die Lokalisierung unterstützt
Erzählen Sie uns von Ihrem Ansatz zur Skalierbarkeit und Leistung
Diese Fragen fühlen sich offen, partnerschaftlich und anbieterfreundlich an. Sie wirken auch informativ.
In der Praxis führen sie jedoch zu drei systemischen Problemen.
Erstens laden sie zur Interpretation ein. Jeder Anbieter beantwortet eine subtly andere Frage.
Zweitens belohnen sie Marketingstärke anstelle von tatsächlicher Produktwahrheit. Narrative Antworten klingen überzeugend, selbst wenn eine Funktion nur lückenhaft vorhanden, auf der Roadmap geplant oder bloß angenommen ist.
Drittens machen sie einen objektiven Vergleich unmöglich. Bewertungsdiskussionen driften schnell von Beweisen zu Meinungen ab, und die Punktevergabe wird eher zu einer Übung in Überzeugungskraft als zu einer echten Bewertung.
An diesem Punkt ist der RFP-Prozess bereits kompromittiert – selbst wenn jeder andere Schritt perfekt ausgeführt wird.
Der Moment, in dem alles schiefgeht: Subjektive Anforderungen
Das häufigste Fehlermuster, das wir beobachten, beginnt mit einem einzigen Wort:
„Beschreiben.“
Zum Beispiel:
„Beschreiben Sie die Suchfunktion im CMS.“
Diese Anforderung kann nicht objektiv bewertet werden. Es gibt keine gemeinsame Definition von Erfolg, keinen messbaren Schwellenwert und keine Möglichkeit, die Konformität mit Gewissheit festzustellen.
Jeder Anbieter kann positiv antworten, ohne sich auf etwas Überprüfbares festlegen zu müssen.
Was folgt, ist vorhersehbar:
Prüfer füllen Lücken mit Annahmen
Workshops werden genutzt, um grundlegende Funktionen zu klären
Vertragsverhandlungen versuchen nachträglich, den Leistungsumfang festzulegen
Die Bereitstellung offenbart nicht übereinstimmende Erwartungen
Das RFP scheiterte nicht, weil die Anbieter unehrlich waren. Es scheiterte, weil die Anforderungen es ihnen erlaubten, vage zu bleiben.
Was hervorragende RFP-Verfasser anders machen
Starke RFP-Verfasser gehen ganz anders an Anforderungen heran.
Anstatt Anbieter zu fragen, wie etwas funktioniert, definieren sie zu Beginn, was erfüllt sein muss, damit die Lösung akzeptabel ist.
Sie nehmen einen übergeordneten Produktbedarf oder eine User Story und zerlegen diese in eine Reihe von atomaren, testbaren Aussagen.
Jede Aussage ist:
Klar
Eindeutig
Messbar
Unabhängig bewertbar
Entscheidend ist, dass jede Aussage nur eine von zwei Antworten zulässt: Wahr oder Falsch.
Beispielsweise, anstatt nach der Suchfunktion zu fragen:
Die Lösung MUSS die Suche über alle im CMS gespeicherten Metadatenattribute für jedes beliebige Objekt unterstützen.
Die Lösung MUSS die Suche in allen Sprachen unterstützen, die innerhalb eines mehrsprachigen Artikels definiert sind.
Die Lösung MUSS unter normalen Betriebsbedingungen Suchergebnisse innerhalb von zwei Sekunden für Datenbestände von bis zu X Millionen Objekten liefern. (Und vergessen Sie nicht zu definieren, was normale Betriebsbedingungen sind!)
Es gibt keinen Interpretationsspielraum. Entweder ist die Funktion vorhanden oder nicht.
Dieser Ansatz verändert die Natur der Ausschreibung grundlegend.
Warum binäre Anforderungen die Ergebnisse transformieren
Wenn Anforderungen als objektive Aussagen und nicht als narrative Aufforderungen formuliert werden, passieren sofort mehrere Dinge.
Die Antworten der Anbieter werden kürzer und präziser. Marketingsprache verschwindet, da sie nicht mehr hilfreich ist.
Funktionslücken treten frühzeitig zutage. Anbieter sind gezwungen, Einschränkungen, Abhängigkeiten oder Roadmap-Elemente explizit offenzulegen.
Die Bewertung wird schneller und nachvollziehbarer. Bewertungsdiskussionen basieren auf Beweisen statt auf Meinungen.
In Workshops geht es um Validierung und Tiefe, nicht um grundlegende Klärungen.
Vor allem aber lassen sich Verträge leichter verhandeln. Die Anforderungsmatrix definiert bereits die akzeptable Mindestfunktionalität, was Unklarheiten und das Risiko von Streitigkeiten verringert.
Dies ist der effektivste Weg, um nachträgliche Änderungsanträge, kommerzielle Reibungsverluste und Enttäuschungen bei der Umsetzung zu reduzieren.
User Stories in Anforderungen übersetzen, ohne die Zukunft zu verbauen
Eine der häufigsten Sorgen bei der Formulierung hochspezifischer, messbarer Anforderungen ist, dass sie die Lösung zu stark einschränken.
Diese Sorge ist berechtigt – aber sie ist kein Grund, vage Anforderungen zu akzeptieren. Sie ist ein Signal dafür, dass Anforderungen mit Bedacht formuliert werden müssen.
Spezifische und objektive Anforderungen sollten nicht beschreiben, wie eine Lösung aufgebaut ist. Sie sollten das Verhalten definieren, das gegeben sein muss, während sie gleichzeitig bewusst Raum für Weiterentwicklung, Rekonfiguration und zukünftige Änderungen lassen.
Diese Unterscheidung ist entscheidend.
Schlecht geschriebene Anforderungen zementieren die Annahmen von heute:
Sie schreiben interne Architekturen vor
Sie fordern bestimmte Implementierungsmuster
Sie verankern aktuelle organisatorische Einschränkungen als dauerhafte Wahrheiten
Gut geschriebene Anforderungen tun das Gegenteil. Sie definieren Ergebnisse, die einen „Architect-for-Change“-Ansatz unterstützen.
Zum Beispiel:
Anstatt:
Die Lösung MUSS Technologie X verwenden, um die mehrsprachige Suche zu unterstützen.
Bevorzugen Sie:
Die Lösung MUSS die Suche in allen innerhalb eines mehrsprachigen Artikels definierten Sprachen unterstützen, ohne dass für jede zusätzliche Sprache eine individuelle Entwicklung erforderlich ist.
Anstatt:
Das CMS MUSS mit einem festen Inhaltsmodell konfiguriert werden, das bei der Implementierung definiert wird.
Bevorzugen Sie:
Das CMS MUSS es autorisierten Benutzern ermöglichen, Inhaltsmodelle ohne Codeänderungen oder erneute Bereitstellung der Plattform zu erweitern und zu ändern.
In beiden Fällen ist die Anforderung immer noch binär und testbar, aber sie bewahrt die Flexibilität zur Anpassung.
So werden zukünftige Änderungen verantwortungsvoll gemanagt. Sie sagen nicht voraus, was die Plattform einmal werden muss. Sie stellen lediglich sicher, dass sie sich verändern kann, wenn sich das Geschäft unweigerlich weiterentwickelt.
Übergeordnete User Stories spielen nach wie vor eine wichtige Rolle. Sie drücken Absicht und Richtung aus. Der Bewertungsmechanismus bleibt jedoch der Anforderungskatalog, der darauf ausgelegt ist, funktionale Fähigkeiten zu testen, und nicht Designvorlieben.
Diese Balance ist schwer zu erreichen. Es erfordert Erfahrung, um zu wissen, welche Einschränkungen das Unternehmen schützen und welche lediglich das aktuelle Denken konservieren.
Dieses Urteilsvermögen macht den Unterschied aus zwischen Anforderungen, die gut altern, und solchen, die bereits vor der Vertragsunterzeichnung veraltet sind.
Warum das Schreiben großartiger Anforderungen wirklich schwer ist
Es gibt einen Grund, warum dieser Ansatz selten gut umgesetzt wird.
Das Formulieren von Anforderungen, die spezifisch, klar, messbar und objektiv sind, ist keine rein administrative Aufgabe. Es ist eine analytische Disziplin an der Schnittstelle von Produktdenken, Systemtechnik, operativer Realität und kommerziellem Risiko.
In den meisten Unternehmen sehen wir schlichtweg nicht viele Menschen, die dies konstant leisten können.
Aus diesem Grund ziehen Unternehmen, die komplexe Medien- und Plattformprogramme durchführen, oft spezialisierte Experten für Ausschreibungen und RFPs hinzu, wenn die Entscheidung langfristige Risiken birgt.
Verfasser von Anforderungen müssen in der Lage sein:
Nutzerbedürfnisse zu verstehen, ohne User Stories wortwörtlich zu kopieren
Abstrakte Geschäftsziele in konkretes Systemverhalten zu übersetzen
Skalierung, Grenzfälle und Fehlerszenarien vorzusehen
Unklarheiten zu beseitigen, ohne die Umsetzung zu stark einzuschränken
Aussagen zu formulieren, die testbar, vertretbar und vertragsreif sind
Diese Kombination von Fähigkeiten ist selten. Infolgedessen werden Anforderungen oft von Ausschüssen verfasst, durch Kompromisse verwässert oder an Teams delegiert, denen die nötige Erfahrung fehlt. Das Ergebnis ist vorhersehbar: gut gemeinte Dokumente, die das Unternehmen letztlich nicht schützen.
Dies ist auch der Grund, warum strenge Anforderungen intern oft als unangenehm empfunden werden. Sie erzwingen Entscheidungen früher, als es viele Organisationen gewohnt sind. Sie legen Unsicherheiten offen. Sie nehmen die Komfortzone vager Formulierungen weg.
Warum alles andere immer noch wichtig ist … nur nicht so sehr
Zeitpläne sind wichtig. Governance ist wichtig. Kommunikation ist wichtig. Fairness ist wichtig.
Aber nichts davon kann schwache Anforderungen kompensieren.
Ein perfekt durchgeführter RFP-Prozess, der auf unklaren Anforderungen basiert, wird dennoch zu einem schlechten Ergebnis führen. Ein weniger eleganter Prozess, der auf präzisen, objektiven Anforderungen aufbaut, ist trotz Mängeln an anderer Stelle oft erfolgreich.
Diese Hierarchie ist unbequem, insbesondere in einkaufsorientierten Umgebungen. Aber sie spiegelt die Realität wider.
Wenn Sie eine Sache ändern, dann diese
Wenn Sie kurz davor stehen, eine Ausschreibung zu veröffentlichen, überprüfen Sie sie mit einer Frage im Hinterkopf:
Kann jede Anforderung ohne Diskussion objektiv bewertet werden?
Wenn die Antwort „Nein“ lautet, sollten Sie genau dort Ihre Arbeit ansetzen.
Dies richtig zu machen, erfordert Zeit und Disziplin. Es erfordert, vagen Formulierungen zu widerstehen und früher für Klarheit zu sorgen, als es sich bequem anfühlt.
Der Nutzen ist beträchtlich.
Spicy Mango verfügt über umfangreiche RFP-Frameworks und Anforderungsbibliotheken für OTT-, Streaming- und Digital-Publishing-Plattformen, die auf realer Projekterfahrung basieren. Wir lizenzieren Referenzmaterial, das Hunderte von übergeordneten funktionalen und nicht-funktionalen Anforderungen in Tausende von präzisen, klaren und messbaren Aussagen übersetzt hat. Diese Tiefe ist einer der Gründe, warum namhafte Medienunternehmen uns mit der Gestaltung und Umsetzung strategischer Transformationsprogramme beauftragen – nicht nur, um den Einkauf zu steuern, sondern um auf Anforderungsebene zu definieren, wie Erfolg tatsächlich aussieht. Wenn Sie diese Arbeit beschleunigen möchten, ohne an Gründlichkeit einzubüßen, kontaktieren Sie uns, um zu sehen, wie eine exzellente Umsetzung in der Praxis aussieht.




