B2B-Case-Study erstellen: Kundenprojekte aus IT und Software überzeugend aufbereiten
Der Go-live ist abgeschlossen. Die neue Plattform läuft, die wichtigsten Systeme sind angebunden und das Projektteam arbeitet bereits an den nächsten Aufgaben. Für eine Case Study scheint damit alles vorhanden zu sein.
Bei der Materialsammlung zeigt sich jedoch schnell, wie verteilt das Wissen über das Vorhaben ist. Die ursprünglichen Anforderungen stehen im Briefing. Technische Entscheidungen finden sich in Präsentationen, Dokumentationen und Abstimmungen. Ergebnisse liegen in Reports oder Systemdaten. Der Vertrieb weiß, welche Argumente beim Kunden besonders wichtig waren. Die beteiligten Fachexperten können erklären, warum bestimmte Architektur- oder Implementierungswege gewählt wurden.
Aus einem abgeschlossenen Kundenprojekt entsteht deshalb noch keine überzeugende B2B-Case-Study.
Die redaktionelle Aufgabe besteht darin, diese Informationen zu einer schlüssigen Projektgeschichte zu verbinden:
Ausgangssituation → Entscheidung → Umsetzung → Wirkung → Nachweis
Für potenzielle Kunden wird ein solches Projekt vor allem dann interessant, wenn sie die Zusammenhänge nachvollziehen können. Wie sah die Ausgangssituation aus? Welche fachlichen und technischen Anforderungen mussten berücksichtigt werden? Warum wurde dieser Lösungsweg gewählt? Wie wurde er umgesetzt und was hat sich anschließend verändert?
Mit zunehmendem Interesse werden auch die Details wichtiger. Welche Systeme wurden eingebunden? Welche Abhängigkeiten spielten bei der Umsetzung eine Rolle? Welche Anforderungen waren für Architektur und Betrieb entscheidend? Und wodurch lassen sich die beschriebenen Ergebnisse belegen?
Eine Case Study verbindet diese Ebenen zu einem Gesamtbild. So können potenzielle Kunden einordnen, wie die Lösung unter realen Bedingungen eingesetzt wurde, welche Entscheidungen das Projekt geprägt haben und welche Erfahrungen für eine vergleichbare Aufgabenstellung relevant sein können.
Welches IT- oder Softwareprojekt eignet sich für eine Case Study?
Stehen mehrere Kundenprojekte zur Wahl, helfen drei Fragen bei der Entscheidung:
- Welche Ausgangssituation lässt sich am präzisesten darstellen?
- Wo sind Lösungsweg und Wirkung am besten dokumentiert?
- Welches Projekt bietet die stärksten Belege für eine fundierte Case Study?
Besonders wertvoll sind Projekte, deren Erfahrungen sich auf vergleichbare Aufgabenstellungen übertragen lassen.
Je nach Leistungsportfolio eignen sich dafür unterschiedliche Projektarten:
Integrations- und Plattformprojekte mit klaren Systembeziehungen
Bei Integrations- und Plattformprojekten stehen bestehende Systembeziehungen, technische Abhängigkeiten und die Entwicklung einer neuen Architektur im Mittelpunkt.
Das Beispiel der zentralen API-Plattform zeigt diese Logik: ERP, CRM, Kundenportal und Serviceplattform sind zunächst über einzelne Punkt-zu-Punkt-Verbindungen gekoppelt. Mit der späteren Plattform erhält die Integrationslandschaft eine neue Struktur. Ausgangslage, Architekturentscheidung und Ergebnis lassen sich dadurch unmittelbar miteinander verbinden.
Migrationen und Modernisierungen mit deutlicher Veränderung
Migrationen und Modernisierungen bieten eine gute Grundlage, wenn sich bestehende und neue Umgebung präzise gegenüberstellen lassen.
Aussagekräftig wird die Entwicklung vor allem dann, wenn technische Abhängigkeiten, Auswahlkriterien und Vorgehen dokumentiert sind. So wird erkennbar, welche Ziele die Modernisierung verfolgt hat, wie der Übergang gestaltet wurde und welche Verbesserungen gegenüber der bisherigen System- oder Anwendungsstruktur erreicht wurden.
Software-Einführungen mit sichtbarer Prozesswirkung
Bei Software-Einführungen rücken Anwendung und Veränderungen im Arbeitsalltag stärker in den Vordergrund.
Einen hohen Informationswert bieten Vorhaben, bei denen deutlich wird, wie die Lösung in vorhandene Prozesse und Systeme eingebunden wurde. Verbesserungen bei Abläufen, Datenflüssen, Rollen oder der Zusammenarbeit zwischen Anwendungen zeigen anschließend, welche Wirkung die Einführung im Unternehmen entfaltet.
Infrastruktur- und Betriebsprojekte mit konkreten Ergebnissen
Infrastruktur- und Betriebsprojekte gewinnen als Case Study an Substanz, wenn technische oder operative Entwicklungen konkret beschrieben werden können.
Dazu gehören etwa neue Betriebsstrukturen, zentralisierte Funktionen, höhere Verfügbarkeit, zusätzliche Skalierungsmöglichkeiten oder weiterentwickelte Sicherheits- und Betriebsmechanismen. Dokumentierte Kennzahlen und technische Fakten geben diesen Ergebnissen zusätzliche Aussagekraft.
Dazu gehören etwa neue Betriebsstrukturen, zentralisierte Funktionen, höhere Verfügbarkeit, zusätzliche Skalierungsmöglichkeiten oder weiterentwickelte Sicherheits- und Betriebsmechanismen. Dokumentierte Kennzahlen und technische Fakten geben diesen Ergebnissen zusätzliche Aussagekraft.
Steht statt eines konkreten Kundenprojekts eine umfassendere Fach- oder Entscheidungsfrage im Mittelpunkt, kann ein Whitepaper für IT-Unternehmen das passendere Format sein.
Was eine B2B-Case-Study über ein IT-Projekt vermitteln sollte
Eine B2B-Case-Study ordnet ein, welche Aufgabe hinter einem IT- oder Softwareprojekt stand, welche fachlichen und technischen Anforderungen berücksichtigt wurden und wie die gewählte Lösung unter realen Bedingungen eingesetzt wurde.
Gerade bei komplexen IT- und Softwareangeboten ist dieser Kontext wichtig. Eine Integrationsplattform lässt sich beispielsweise nicht allein über Funktionen und technische Leistungsmerkmale beurteilen. Für potenzielle Kunden ist ebenso relevant, welche Systemlandschaft vorhanden war, welche Kriterien zur neuen Architektur geführt haben und was sich nach der Einführung verändert hat.
Die einzelnen Bestandteile der Case Study übernehmen dabei unterschiedliche Aufgaben:
Ausgangssituation: den Projektkontext einordnen
Am Anfang steht der fachliche, technische und organisatorische Rahmen. Welche Systemlandschaft war vorhanden? Welche Abläufe, Schnittstellen oder Abhängigkeiten prägten die Situation? Und welche Aufgabe sollte mit dem Vorhaben gelöst werden?
Diese Einordnung schafft die Grundlage, um spätere Entscheidungen und Ergebnisse im richtigen Zusammenhang zu verstehen.
Entscheidung: Anforderungen und Lösungsweg verbinden
An die Ausgangslage schließt die Frage an, warum genau dieser Lösungsweg gewählt wurde.
Bei einer Integrationsplattform kann dazu gehören, welche Systeme angebunden werden sollten, welche Abhängigkeiten berücksichtigt werden mussten und welche Kriterien für die künftige Architektur maßgeblich waren. Dadurch wird erkennbar, wie sich die gewählte Lösung aus der konkreten Situation ableitete.
Umsetzung: technische Zusammenhänge verständlich darstellen
Bei der Umsetzung rücken die Maßnahmen und technischen Entscheidungen in den Mittelpunkt, die für den weiteren Verlauf entscheidend waren.
Dazu können Architekturentscheidungen, Integrationen, Migrationsschritte, Konfigurationen oder Veränderungen an bestehenden Systembeziehungen gehören. Ausgewählt werden vor allem die Details, die den Lösungsweg und seine Wirkung verständlicher machen.
Wirkung: Veränderungen nach der Einführung sichtbar machen
Nach der Umsetzung interessiert vor allem, was sich im Betrieb, in Prozessen oder in der technischen Struktur verändert hat.
Das können beispielsweise eine neue Integrationsarchitektur, zentral bereitgestellte Funktionen, vereinfachte Abläufe oder zusätzliche Möglichkeiten für den Ausbau der Systemlandschaft sein. So wird deutlich, welchen konkreten Beitrag die Lösung im Unternehmen leistet.
Nachweis: Ergebnisse mit belastbaren Angaben stützen
Aussagekräftig wird die Case Study, wenn zentrale Ergebnisse durch passende Belege gestützt werden.
Dafür kommen je nach Vorhaben Kennzahlen, Systemdaten, Projektdokumentationen, technische Fakten oder freigegebene Kundenaussagen infrage. So erhält jede zentrale Aussage genau den Nachweis, der sie tatsächlich stützt.
Erst im Zusammenspiel dieser Ebenen entsteht aus einzelnen Projektinformationen eine schlüssige Case Study. Welche Kundenprojekte dafür besonders geeignet sind, hängt davon ab, wie klar sich Ausgangslage, Lösungsweg und Ergebnisse dokumentieren und belegen lassen.
Den Aufbau der B2B-Case-Study an den Fragen potenzieller Kunden ausrichten
Wie diese fünf Ebenen zusammenspielen, zeigt das Beispiel der zentralen API-Plattform. Entscheidend ist dabei nicht allein, was im Projekt umgesetzt wurde.
Bei der Aufbereitung einer Case Study lohnt sich der Blick darauf, welche Inhalte Entscheider für die Bewertung komplexer IT-Angebote brauchen. Das konkrete Kundenprojekt liefert dafür die Antworten aus der Praxis.
Ausgangssituation: Ist die Aufgabe mit meiner Situation vergleichbar?
Zu Beginn zeigt die Case Study, unter welchen Bedingungen das Projekt gestartet ist.
Beim Beispiel der API-Plattform sind ERP, CRM, Kundenportal und Serviceplattform über individuell entwickelte Punkt-zu-Punkt-Verbindungen gekoppelt. Änderungen an einzelnen Anwendungen erfordern Anpassungen an mehreren Schnittstellen. Mit zusätzlichen Systemen wächst zugleich der Aufwand für Abstimmung, Pflege und Integration.
Unternehmen mit einer ähnlich gewachsenen Integrationslandschaft können dadurch Parallelen zur eigenen Ausgangslage erkennen und einordnen, welche Anforderungen sich daraus für eine zukünftige Architektur ergeben.
Entscheidung: Warum passt dieser Lösungsweg zur Aufgabe?
An die Ausgangslage schließt die Frage an, welche Kriterien die Architekturentscheidung geprägt haben.
Die neue Struktur soll vorhandene und künftige Anwendungen über eine gemeinsame Integrationsschicht verbinden. Wiederverwendbare Schnittstellen, einheitliche Zugriffskontrolle, zentrales Monitoring und Erweiterbarkeit werden deshalb zu wesentlichen Anforderungen an die Plattform.
Damit wird verständlich, warum eine zentrale API-Plattform gewählt wurde und welche Funktion sie innerhalb der Systemlandschaft übernimmt. Die Architekturentscheidung lässt sich so mit den Anforderungen einer eigenen Integrationsaufgabe vergleichen.
Umsetzung: Wie wurde die Lösung unter realen Bedingungen eingeführt?
Anschließend rückt die praktische Einführung in den Mittelpunkt.
Beim API-Projekt werden bestehende Schnittstellen schrittweise auf die neue Struktur übertragen, Zugriffe vereinheitlicht und Monitoring-Funktionen zentral aufgebaut. Zunächst können ausgewählte Verbindungen zwischen ERP, CRM und Kundenportal migriert werden, bevor weitere Anwendungen folgen.
Relevant sind dabei vor allem jene technischen Details, die den Verlauf des Projekts erklären. Dazu gehören beispielsweise Abhängigkeiten zwischen Systemen, die Reihenfolge einzelner Schritte oder Architekturentscheidungen, die Kompatibilität und Erweiterbarkeit unterstützen.
So werden die technischen Rahmenbedingungen einer vergleichbaren Einführung greifbar.
Wirkung: Welchen konkreten Nutzen bringt die neue Struktur?
Nach der Einführung zeigt sich, welchen Beitrag die neue Architektur für Betrieb und Weiterentwicklung leistet.
Weitere Anwendungen können vorhandene APIs nutzen und neue Anbindungen auf bestehenden Integrationsbausteinen aufsetzen. Zugriffe und Monitoring-Funktionen werden zentral gesteuert, während Integrationen einer gemeinsamen Architektur folgen.
Damit verändert sich nicht nur die technische Struktur. Auch spätere Erweiterungen und zusätzliche Systemanbindungen können auf einer bereits etablierten Integrationslogik aufbauen.
Vorliegende Projektdaten können diese Wirkung zusätzlich präzisieren. Dazu gehören etwa die Zahl überführter Schnittstellen, angebundener Anwendungen oder wiederverwendeter APIs. Zeit-, Aufwands- oder Kosteneffekte ergänzen die Darstellung, sofern dafür belastbare Daten vorliegen.
Nachweis: Woran lässt sich die Wirkung erkennen?
Konkrete Belege zeigen, worauf die beschriebenen Ergebnisse beruhen.
Die Zahl migrierter Schnittstellen dokumentiert beispielsweise den Umfang der Überführung. Die Nutzung vorhandener APIs durch weitere Anwendungen belegt ihre Wiederverwendbarkeit. Ein Vergleich der Integrationsstruktur vor und nach der Einführung macht die technische Entwicklung sichtbar.
Kundenaussagen ergänzen diese Fakten um die praktische Perspektive. Sie können einordnen, wie sich die neue Struktur auf Erweiterungen, Abstimmungen, Betrieb oder weitere Integrationsvorhaben auswirkt.
So verbindet die Case Study technische Umsetzung, konkrete Wirkung und belastbare Nachweise zu einer Darstellung, die potenziellen Kunden eine fundierte Einordnung der Lösung ermöglicht.
Auch technische und qualitative Ergebnisse können viel aussagen
Bei Integrations-, Infrastruktur-, Security- oder Modernisierungsvorhaben liegt ein wesentlicher Teil der Wirkung häufig in der technischen und operativen Struktur.
Verbesserte Systembeziehungen, zentralisierte Funktionen, weiterentwickelte Betriebsstrukturen oder neue Integrationsmöglichkeiten können deshalb ebenso aussagekräftige Projektergebnisse sein wie messbare Zeit-, Kosten- oder Umsatzeffekte.
Bei der API-Plattform können Punkt-zu-Punkt-Verbindungen abgelöst, Schnittstellen zentral bereitgestellt und Zugriffe vereinheitlicht worden sein. Monitoring-Funktionen stehen an einer gemeinsamen Stelle zur Verfügung. Neue Anwendungen nutzen vorhandene Integrationsmechanismen.
Solche Veränderungen sind bereits aussagekräftig, wenn sie präzise beschrieben werden.
Die Case Study kann zeigen, dass neue Anwendungen nicht mehr für jede Verbindung eine eigene Integrationslogik benötigen, sondern auf bereits bereitgestellte APIs zugreifen.
Damit wird die Wirkung auch ohne zusätzliche ROI-Zahl greifbar.
Projektwissen aus Unterlagen und Gesprächen zusammenführen
Für eine fundierte Case Study werden technische Daten, festgehaltene Entscheidungen und Erfahrungen aus dem Projektverlauf miteinander verbunden.
Projektdokumentation gezielt auswerten
Briefings, Architekturunterlagen, Spezifikationen, Projektpläne, Reports und Systemdaten liefern Informationen zu Ausgangssituation, Anforderungen, Umsetzung und Ergebnissen. Architekturdiagramme können beispielsweise Systembeziehungen und Schnittstellen sichtbar machen, während Monitoring-Daten Entwicklungen im Betrieb erfassen.
Die Auswertung orientiert sich bereits an der späteren Struktur der Case Study. Dadurch lässt sich erkennen, welche Aussagen durch vorhandenes Material gestützt werden und welche Zusammenhänge im weiteren Austausch vertieft werden sollten.
Entscheidungsgründe mit Fachexperten abstimmen
Gespräche mit Solution Architects, Entwicklern, Consultants oder Projektverantwortlichen erschließen die Hintergründe wesentlicher Weichenstellungen. Sie zeigen beispielsweise, welche Abhängigkeiten berücksichtigt wurden, welche Kriterien für die gewählte Architektur maßgeblich waren oder wodurch die Reihenfolge einzelner Umsetzungsschritte bestimmt wurde.
So wird nicht nur sichtbar, was umgesetzt wurde. Auch der Lösungsweg und die dahinterstehende fachliche und technische Logik werden deutlich.
Die praktische Wirkung mit dem Kunden klären
Im Austausch mit dem Kunden wird deutlich, wie sich die realisierte Lösung in Anwendung und Betrieb bewährt. Relevant ist beispielsweise, welchen Beitrag veränderte Systembeziehungen, neue Integrationsmöglichkeiten oder zentral bereitgestellte Funktionen im Arbeitsalltag leisten und welche weiteren Entwicklungen darauf aufbauen können.
Diese Perspektive verbindet die realisierte technische Lösung mit ihrer Bedeutung in der Praxis. Kundenaussagen können zugleich die vorliegenden Fakten um Erfahrungen aus Anwendung und Betrieb erweitern.
Vertraulichkeit und Freigabe früh berücksichtigen
Vertrauliche IT- und Softwareprojekte können fachlich konkret dargestellt werden, wenn früh feststeht, welche Informationen veröffentlicht, abstrahiert oder vor ihrer Verwendung abgestimmt werden.
Diese Klärung beginnt bereits bei der Recherche und schafft einen verlässlichen Rahmen für die weitere Ausarbeitung.
Den Rahmen für die Veröffentlichung bestimmen
Zunächst wird definiert, welche Projektdetails in die Ausarbeitung einfließen dürfen. Dazu zählen beispielsweise Architekturinformationen, Sicherheitsaspekte, interne Prozesse, Leistungsdaten, Systembezeichnungen sowie Angaben zu Kosten oder Umfang.
Für die einzelnen Inhalte wird entschieden, in welcher Form sie verwendet werden. Dadurch entsteht früh eine verlässliche Grundlage für die weitere Ausarbeitung.
Vertrauliche Details sinnvoll abstrahieren
Auch eine anonymisierte Darstellung kann konkrete Zusammenhänge vermitteln.
Beim Beispiel der API-Plattform müssen etwa keine bestimmten ERP-, CRM- oder Serviceprodukte genannt werden. Systemtypen, ihre Funktion innerhalb der Integrationslandschaft sowie Anzahl und Art der angebundenen Anwendungen schaffen bereits einen aussagekräftigen fachlichen Kontext.
Architekturprinzip, Aufgabenstellung und Veränderungen nach der Einführung können ebenfalls beschrieben werden, während interne Produktnamen oder sensible Einzelheiten außen vor bleiben.
Aussagen, Kennzahlen und Zitate abstimmen
Vor der finalen Fassung werden die relevanten Inhalte mit den zuständigen Ansprechpartnern geprüft.
Fachexperten bestätigen die Darstellung von Architektur, Systemen und Umsetzung. Kundenzitate erhalten eine ausdrückliche Freigabe. Bei Kennzahlen werden Wert, Zeitraum, Bezugsgröße und erforderlicher Kontext eindeutig festgehalten.
Damit steht vor Abschluss des Textes fest, welche Aussagen in welcher Form verwendet werden. Die Darstellung bleibt fachlich konkret und bewegt sich zugleich innerhalb der vereinbarten Informationsgrenzen.
Die Case Study vor Veröffentlichung prüfen
Zum Abschluss geht es darum, ob Ausgangslage, Lösungsweg, Umsetzung und Wirkung schlüssig ineinandergreifen, zentrale Aussagen belastbar belegt sind und sich die Erfahrungen auf ähnliche Aufgabenstellungen übertragen lassen.
1. Ausgangslage und Entscheidung abgleichen
Den Anfang bildet der fachliche und technische Kontext. Er muss erkennen lassen, welche Aufgabe bestand und welche Kriterien die Wahl der Lösung geprägt haben.
- Ist die Ausgangslage konkret genug, um die zentrale Aufgabe zu verstehen?
- Ergeben sich die Anforderungen schlüssig aus den beschriebenen Rahmenbedingungen?
- Wird deutlich, warum die gewählte Lösung dazu passt?
Damit ist geklärt, ob die weitere Darstellung auf einer stimmigen Grundlage aufbaut.
2. Umsetzung und Detailtiefe abstimmen
Im nächsten Schritt steht die praktische Durchführung im Mittelpunkt. Technische Einzelheiten erhalten dort Raum, wo sie zum Verständnis wesentlicher Entscheidungen oder späterer Veränderungen beitragen.
- Greift die Umsetzung die zuvor definierten Anforderungen auf?
- Erklären die ausgewählten Details die entscheidenden fachlichen und technischen Zusammenhänge?
- Entspricht die Tiefe den Fragen der jeweiligen Lesergruppen?
So bleibt die fachliche Substanz erhalten und der Fokus liegt auf den Informationen, die für die Einordnung des Vorhabens wichtig sind.
3. Wirkung und Belege verbinden
Anschließend wird betrachtet, was sich durch das Vorhaben verändert hat und worauf diese Aussagen beruhen. Entscheidend ist dabei sowohl das Ergebnis als auch seine Bedeutung für den Kunden.
- Sind quantitative, qualitative und technische Ergebnisse eindeutig eingeordnet?
- Wird der konkrete Nutzen der Veränderungen sichtbar?
- Sind Belege direkt den jeweiligen Aussagen zugeordnet?
- Stützen Projektdaten, technische Fakten oder freigegebene Kundenaussagen die dargestellte Wirkung?
Damit stehen Ergebnis und Nachweis in einem klaren Zusammenhang.
4. Übertragbarkeit bewerten
Schließlich richtet sich der Blick auf den Informationswert für potenzielle Kunden. Die Darstellung braucht genügend Kontext, damit sie erkennen können, welche Erfahrungen aus dem Projekt für eine vergleichbare Aufgabenstellung relevant sind.
- Wird deutlich, unter welchen fachlichen und technischen Bedingungen die Lösung eingesetzt wurde?
- Lassen sich die wesentlichen Entscheidungen aus der beschriebenen Ausgangssituation ableiten?
- Ist erkennbar, welche Erfahrungen für vergleichbare Projekte von Bedeutung sind?
So zeigt sich, ob die Case Study das konkrete Vorhaben präzise vermittelt und zugleich eine fundierte Orientierung für ähnliche Aufgabenstellungen bietet.
Häufige Fragen zur Erstellung von B2B-Case-Studies
Welche Informationen sollten bereits während eines IT-Projekts gesichert werden?
Hilfreich sind Unterlagen zur Ausgangssituation, zu Anforderungen, Architekturentscheidungen, Schnittstellen, Abhängigkeiten und zentralen Umsetzungsschritten. Architekturdiagramme, Spezifikationen, Projektberichte und Monitoring-Daten dokumentieren die technische Entwicklung. Ergänzend sollten Ergebnisse, relevante Entscheidungen und mögliche Ansprechpartner für spätere Fach- oder Kundengespräche festgehalten werden.
Welche Ergebnisse eignen sich als Nachweis in einer technischen Case Study?
Entscheidend ist die Verbindung zwischen Aussage und Beleg. Technische Veränderungen können beispielsweise über die Zahl migrierter Schnittstellen, angebundener Systeme oder wiederverwendeter APIs dokumentiert werden. Für Aussagen zu Betrieb und Leistungsfähigkeit kommen je nach Projekt Betriebsdaten, Verfügbarkeitswerte oder andere definierte technische Kennzahlen infrage.
Welche Rolle spielen Kundenaussagen bei IT- und Softwareprojekten?
Kundenaussagen ergänzen Projektdaten um Erfahrungen aus Betrieb und Nutzung. Sie können einordnen, wie sich eine neue Architektur auf Systemanbindungen, Abstimmungen, Betriebsaufgaben oder spätere Erweiterungen auswirkt.
Wer sollte eine technische Case Study vor der Veröffentlichung prüfen?
Die fachliche Abstimmung übernehmen Personen, die Architektur, Systeme und Umsetzung aus dem Vorhaben kennen, etwa Solution Architects, Entwickler, Consultants oder Projektverantwortliche. Kundenspezifische Inhalte, Zitate und Kennzahlen werden zusätzlich mit dem betreffenden Unternehmen abgestimmt.
Sie möchten ein IT- oder Softwareprojekt als Case Study aufbereiten?
Schildern Sie kurz, um welches Kundenprojekt es geht, welche Unterlagen bereits vorliegen und welche Projektdaten, Ergebnisse oder Kundenaussagen für die Ausarbeitung zur Verfügung stehen.
Sie erhalten eine konkrete Einschätzung dazu, wie sich das Projekt als Case Study aufbauen lässt, welche vorhandenen Informationen eine belastbare Grundlage bilden und welche weiteren Angaben für die Ausarbeitung sinnvoll sind.
