Inhalt und Aufbau des Artikels

In diesem Artikel möchte ich auf folgende Punkte eingehen:

1. Was ist ein KI-Projektsteckbrief?
2. Warum der KI-Projektsteckbrief alleine nicht ausreichend ist
3. Vorlage: Universeller KI-Projektsteckbrief

Was ist ein KI-Projektsteckbrief?

Bei einem KI-Projektsteckbrief handelt es sich im Grunde um eine „Kurzbeschreibung“ eines KI-Projektes mit allen wesentlichen Informationen, welche für ein Projekt-Team, Entscheider oder andere Stakeholder relevant sind, um sich ein Bild über das Projekt, die Zielsetzung und Rahmenbedingungen zu machen. Je nach Projektart und Organisation gibt es dabei unterschiedliche Schwerpunkte, Ausgestaltungen oder Formen. Unabhängig vom Projekttyp werden in einem Projektsteckbrief jedoch in der Regel immer die folgenden Punkte behandelt:

• Hintergrund eines Projektes
• Zielsetzung
• Nutzen
• Risiken
• Rahmenbedingungen
• Zeit, Kosten und Organisatorisches
• …

In der Regel wird ein Projektsteckbrief eher kurz und knapp gehalten. Genauere und detailliertere Ausführungen werden in gesonderte Anforderungs- oder IST-Analysen und Dokumente ausgelagert. Diese sind dann die Grundlage für die Erstellung eines Lastenhefts bzw. Spezifikationsdokuments, welches an potenzielle Auftragnehmer zur Angebotserstellung / Pflichtenhefterstellung weitergeleitet wird. Wie eingangs erwähnt gibt es in der Praxis jedoch häufig zwei Probleme:

• Es fehlen die Ressourcen für eine umfangreiche IST- und Anforderungsanalyse.
• Es fehlt das notwendige Wissen, um ein Lastenheft oder Spezifikationsdokument erstellen zu können.

Der Projektsteckbrief ersetzt damit in der Praxis häufig das Lasten- und Pflichtenheft oder ist die Grundlage für Ausschreibungen und Angebote.

Warum der KI-Projektsteckbrief alleine nicht ausreichend ist

Auf Basis meiner Erfahrungen ist dies insbesondere für KI-Projekte nicht ausreichend. Bei der Beratung, Entwicklung oder Einführung von KI-Systemen braucht es bereits zu Beginn ein tiefergehendes Verständnis für die eigentliche Problemstellung, Hintergründe und Rahmenbedingungen, um geeignete Lösungsansätze und die Machbarkeit/Wirtschaftlichkeit abschätzen zu können. Nicht selten ist es der Fall, dass KI gar nicht die beste, wirtschaftlichste oder überhaupt eine geeignete Lösung für eine Problemstellung ist oder mit bestehenden (KI-) Strategien in Konflikt steht. Zusätzlich ist bei der Entwicklung von vertrauensvollen KI-Systemen z. B. nach dem ISO 42001 Standard bereit zu Beginn eine Analyse und Bewertung möglicher Risiken notwendig. Diese ist ohne ein tiefergehendes Verständnis nicht möglich.

Paradoxerweise haben KI-Projekte eine Besonderheit: Trotz sorgfältiger Planung lassen sich zu Beginn selten genaue Aussagen zur Machbarkeit oder Wirtschaftlichkeit von Lösungsansätzen treffen. Der Grund dafür ist, dass jeder Anwendungsfall von individuellen Daten und spezifischen Rahmenbedingungen abhängt. Deshalb ist es entscheidend, mögliche Konzepte und Lösungsansätze schnell in Proof-of-Concepts (PoCs) zu testen. Erst durch diese Praxis zeigt sich, ob ein Ansatz technisch möglich, sinnvoll oder wirtschaftlich tragfähig ist. Zu detaillierte Vorabprüfungen – etwa umfangreiche IST-Analysen oder Anforderungskataloge – verzögern diesen Prozess und erfordern bereits im Vorfeld hohe zusätzliche Kosten.

Es braucht deshalb eine Balance zwischen genug Vorabinformationen, um geeignete Lösungskonzepte oder Strategien entwickeln und bewerten zu können und einer schlanken IST- und Anforderungsanalyse, um schnell und kosteneffizient in die Erprobung einzusteigen.

Aus diesem Grund möchte ich hier eine Vorlage für einen KI-Projektsteckbrief vorstellen, welcher meiner Meinung nach eine gute Brücke zwischen genügend Informationen und überschaubarem Aufwand schlägt. Dieser kann so z. B. im Rahmen eines Discovery Workshops erarbeitet werden und vereint gleichzeitig die wesentlichen Punkte eines Lasten- und Pflichtenhefts.

Vorlage: Universeller KI-Projektsteckbrief

Die folgende Vorlage kann beliebig je nach Anwendungsfall und Umfeld angepasst oder erweitert werden. Genauso können natürlich auch Punkte wegfallen. 

0. Eckdaten

Der Projektkopf mit allen Meta-Informationen zum Projekt auf einen Blick.

• Projektname: Klare, einprägsame Bezeichnung.

• Projekt-ID: Eindeutige interne Identifikation (optional).

• Projektleiter/in: Hauptverantwortliche Person für die Durchführung und Leitung.

• Auftraggeber/Sponsor: Die Person oder Firma, die das Projekt freigegeben hat und finanziert.

• Start-Datum (Geplant): Angestrebtes Datum für den Projektbeginn.

• Geplantes Ende: Angestrebtes Datum für den Projektabschluss.

• Status: Der aktuelle Genehmigungs-/Arbeitsstand.

• Version: Wichtig für das Änderungsmanagement (Welche Fassung ist aktuell?).

• Versionsdatum: Wann wurde das Dokument zuletzt aktualisiert?

• Abteilung/Ressort: Die primär beteiligten oder betroffenen Geschäftsbereiche.

• Fremdfirmen / Partner: Übersicht der (relevanten) externen Partner, welche an dem Projekt beteiligt sind.

• Dokumentationsort: Falls es Dokumente zum Projekt gibt.

• Sonstiges: Sonstige relevante Informationen.

1. Ausgangslage (IST- und Anforderungsanalyse)

Bei der Ausgangslage handelt es sich im Grunde um eine komprimierte IST- und Anforderungsanalyse. Der Schwerpunkt liegt dabei auf den Hintergründen und der aktuellen Situation (IST), der eigentlichen Problemstellung und Zielsetzung sowie möglichen Anforderungen.

1.1 Einleitung und allgemeine Hintergründe (IST-Stand)

Mögliche Fragen oder Inhalte:

• Wer ist die Firma, Branche und was ist der Hintergrund?
• Was sind die Geschäftsziele / Modelle der Firma?
• Welche regulatorische sowie rechtliche Bestimmungen oder Anforderungen gelten für die Firma oder unterliegt diese?
• (KI) Wird im Unternehmen bereits KI eingesetzt (Tool, Anbieter etc.) und welche Erfahrungen wurden damit gemacht?
• (KI) Gibt es einen KI-Beauftragten im Unternehmen?
• (KI) Gibt es eine Technologie-, Daten- oder KI-Strategie?
• (…)

1.2 Problemstellung, Use Case oder Business Case

Mögliche Fragen oder Inhalte:

• Was ist der Hintergrund bzw. die Ausgangslage der Problemstellung?
• Was ist das konkrete Problem bzw. Herausforderung?
• Welche Abteilung / Bereich / Person ist von der Problemstellung betroffen oder soll mit der späteren Lösung arbeiten?
• Gibt es einen Prozess zur Problemstellung?
• Wie könnte / soll eine potenzielle Lösung aussehen (Ideale Lösung)?
• Gibt es eine favorisierte Lösung (Falls es mehrere bekannte Alternativen gibt)?
• (…)

1.3 Bisherige Lösungsansätze oder Vorschläge

Mögliche Fragen oder Inhalte:

• Was wurde bereits zur Lösung der Problemstellung(en) ausprobiert?

• Warum ist die aktuelle Lösung nicht ausreichend oder erfolgreich?

• Welche bekannten Lösungsalternativen gibt es?

• Gibt es KPIs / Kennzahlen, über welche die Performance der aktuellen Lösung gemessen wird

• Welche bisherigen Initiativen oder sonstigen Projekte haben mit dieser Thematik zu tun?

• (…)

1.4 Zielsetzung(en) und Mehrwerte

Mögliche Fragen oder Inhalte:

• Welche Ziele / Mehrwerte sollen mit der Lösung der Problemstellung oder dem Use Case erreicht werden (z. B. Reduzierung der Fehlerrate um 10% in Zeitraum XYZ)?

• Was soll mit KI gelöst werden bzw. was ist die konkrete Erwartungshaltung an KI?

• Wie kann oder soll der Erfolg / Mehrwert / Ziele gemessen werden?

• Gibt es messbare Kriterien (KPIs) für den Erfolg / Mehrwert / Ziele?

• Bei mehreren Ziele, was wären Primärziele und was Sekundärziele? (Priorisierung)

• (…)

1.5 Anforderungen & Akzeptanzkriterien

Was soll die Lösung auf jeden Fall können, beinhalten oder berücksichtigen? Hier wird in der Regel nur auf die wesentlichen funktionalen und nicht funktionalen Anforderungen eingegangen (was eine Lösung für die Problemstellung oder der geplante Use Case auf jeden Fall umfassen muss). Der Punkt kann natürlich beliebt detailliert ausgearbeitet werden. Es empfiehlt sich jedoch, dann ein eigenes Dokument für die Anforderungsanalyse und Definition zu nutzen.

Typische Anforderungskategorien wären z. B. die folgenden:

• Funktionale Anforderungen

• Technische Anforderungen (Technologieauswahl, Tools, Sprachen etc.)

• Nicht-Funktionale Anforderungen (Qualität)

• Anforderungen an Performance und Skalierung

• Anforderungen an Nachvollziehbarkeit und Transparenz

• Anforderungen an Verlässlichkeit, Qualität und Sicherheit

• Anforderungen an Fairness und Einfluss auf die Gesellschaft

• Anforderungen an KI-Modelle und Funktionen

• Anforderungen an Governance, Risiko- und Qualitätsmanagement

• Anforderungen an Lizenzen, Nutzungsrechte und Haftung

• Anforderungen an Datenschutz- und Sicherheit

• Anforderungen an Einführung und Trainings

• Anforderungen an interne und externe Daten

• Regulatorische und rechtliche Anforderungen (Compliance)

• Anforderungen an die Dokumentation

• Anforderungen an Tests und Evaluation

• (…)

1.6 Stakeholder und Ansprechpartner

Mögliche Fragen oder Inhalte:

• Wer sind die Ansprechpartner / Stakeholder (KI-Beauftragter, User, Datenschutz, Compliance, PM, Betriebsrat etc.)?

• Welche Rollen haben die Ansprechpartner / Stakeholder und in welchen Fällen wendet man sich an diese?

• (…)

2. Projektumfang

Nicht immer müssen oder können in einem Projekt alle initialen Anforderungen, Wünsche oder Zielsetzungen umgesetzt werden, da es sich bei den allgemeinen Zielen z. B. um übergeordnete Geschäftsziele handelt. Der Umfang muss damit zu Beginn begrenzt werden, um z. B. im Rahmen von Proof-of-Concepts nur kleine Teilbereiche umzusetzen oder zu verproben. Zu diesem Zweck macht es häufig Sinn die Projektziele getrennt von den allgemeinen Zielen zu definieren.

2.1 Zielsetzung des Projekts (Projektziele)

Mögliche Fragen oder Inhalte:

• Was soll mit dem Projekt erreicht werden (allgemeines Projektziel und Umfang)?

• Welche Teilziele (Meilensteine) sollen innerhalb des Projektes erreicht werden?

• (…)

2.2 Erfolgsmessung und Kriterien

Mögliche Fragen oder Inhalte:

• Wie kann oder soll der Erfolg des Projektes / Mehrwerte / Ziele gemessen werden?

• Was sind die (nicht funktionalen Anforderungen) Kriterien (KPIs) für den Erfolg / Mehrwert / Ziele?

• (…)

2.3 Umfang (Scope / Out-of-Scope)

Mögliche Fragen oder Inhalte:

• Was sind die erwarteten Ergebnisse / Output im Projekt?

• Welche (teil-) Anforderungen sollen im Projekt umgesetzt werden?

• Was ist explizit nicht im Projekt?

• (…)

2.4 Einschränkungen und Rahmenbedingungen

Mögliche Fragen oder Inhalte:

• Welche Rahmenbedingungen gelten für das Projekt oder müssen bei der Umsetzung berücksichtigt werden?

• In welchem Zeitrahmen soll/muss das Projekt durchgeführt oder abgeschlossen sein?

• Welcher Budgetrahmen soll/muss eingehalten werden?

• (…)

3. Risiken und Risikoanalyse

Die Risiken umfassen im Optimalfall die Risiken die sich während des Projektes ergeben können, aber auch die Risiken, welche sich durch die Nutzung, Inbetriebnahme etc. des KI-Systems / der Lösung während des gesamten KI-Lifecycles letztendlich ergeben können. Die Risiken und Maßnahmen führe ich hier immer nochmal aus Sicht des Entwickler / Experten gesondert auf. Für gewöhnlich umfasst ein Arbeitspaket immer auch gesondert das Risikomanagement.

Qualitäts- und funktionsbezogene Risiken

• Welche Risiken bestehen / sind bekannt oder können sich aus dem Projekt ergeben?

• Welches Schadenspotenzial können die Risiken haben?

• Wie hoch wird die Eintrittswahrscheinlichkeit der Risiken geschätzt?

• (…)

Daten- und datenschutzbezogene Risiken

• Welche Risiken bestehen / sind bekannt oder können sich aus dem Projekt ergeben?

• Welches Schadenspotenzial können die Risiken haben?

• Wie hoch wird die Eintrittswahrscheinlichkeit der Risiken geschätzt?

• (…)

Regulatorische und rechtliche Risiken

• Welche Risiken bestehen / sind bekannt oder können sich aus dem Projekt ergeben?

• Welches Schadenspotenzial können die Risiken haben?

• Wie hoch wird die Eintrittswahrscheinlichkeit der Risiken geschätzt?

• (…)

Sonstige Risiken

• Welche Risiken bestehen / sind bekannt oder können sich aus dem Projekt ergeben?

• Welches Schadenspotenzial können die Risiken haben?

• Wie hoch wird die Eintrittswahrscheinlichkeit der Risiken geschätzt?

• (…)

4. Lösungskonzept und Umsetzungsplan

Das Lösungskonzept und der Umsetzungsplan dokumentieren das mögliche Vorgehen oder KI-System, mit welchem die Projektziele umgesetzt oder erreicht werden sollen. Falls mit externen Anbietern zusammengearbeitet wird, können diese hier Ihr jeweiliges Lösungskonzept und Vorgehen beschreiben.

4.1 Lösungskonzept

Mögliche Fragen oder Inhalte:

Beschreibung und Funktionsumfang

• Allgemeine Beschreibung des KI-Systems / Lösungskonzepts (was macht dieses genau?)

• Über welchen Funktionsumfang verfügt das KI-System / Lösungskonzept?

• Welche Eingabedaten (und Form) erwartet oder verarbeitet das KI-System / Lösungskonzept?

• Wie sehen die geplanten Ausgaben aus und welche Form(en) können diese haben?

• (…)

Einsatzkontext und Umgebung

• Wie sieht der potenzielle Einsatzkontext des KI-Systems / Lösungskonzepts aus?

• Hat das KI-System / Lösungskonzept Schnittstellen zu anderen Systemen oder Anwendungen?

• Für welche weiteren Anwendungsfälle ist das KI-System / Lösungskonzept potenziell geeignet oder einsetzbar?

• Welche weiteren Use Cases oder Betriebsumgebungen sind für den Einsatz des KI-Systems / Lösungskonzepts explizit ausgeschlossen?

• (…)

Architektur und Design

• Welche Komponenten oder Verarbeitungsschritte (Pipeline) umfasst das KI-System / Lösungskonzept?

• Wie sieht die Anwendungsarchitektur und das Zusammenspiel der Komponenten aus?

• Auf welche ML-Modell(en) oder Verfahren basiert das KI-System / Lösungskonzept?

• Beinhaltet das KI-System / Lösungskonzept Funktionen zum kontinuierlichen Re-Training oder sieht solche vor?

• (…)

Erfüllung von Qualitäts-, Risiko-, Compliance- und Governance-Risiken oder Anforderungen

• Berücksichtigung von qualitäts- und funktionsbezogenen Risiken und Anforderungen

  • Wie werden die qualitäts- und funktionsbezogenen Risiken / Anforderungen vom KI-System / Lösungskonzept berücksichtigt oder erfüllt (in der Entwicklung und im Betrieb)?

  • Wie wird das Schadenspotenzial oder die Eintrittswahrscheinlichkeit der Risiken vom Lösungskonzept minimiert?

  • Welche weiteren Maßnahmen sind empfohlen?

• Berücksichtigung von daten- und datenschutzbezogenen Risiken und Anforderungen

  • Wie werden die daten- und datenschutzbezogenen Risiken / Anforderungen vom KI-System / Lösungskonzept berücksichtigt oder erfüllt (in der Entwicklung und im Betrieb)?

  • Wie wird das Schadenspotenzial oder die Eintrittswahrscheinlichkeit der Risiken vom Lösungskonzept minimiert?

  • Welche weiteren Maßnahmen sind empfohlen?

• Berücksichtigung von regulatorischen und rechtlichen Risiken und Anforderungen

  • Wie werden die regulatorischen oder rechtlichen Risiken / Anforderungen vom KI-System / Lösungskonzept berücksichtigt oder erfüllt (in der Entwicklung und im Betrieb)?

  • Wie wird das Schadenspotenzial oder die Eintrittswahrscheinlichkeit der Risiken vom Lösungskonzept minimiert?

  • Welche weiteren Maßnahmen sind empfohlen?

• Sonstige Anforderungen oder Risiken

  • Wie werden sonstige Risiken / Anforderungen vom KI-System / Lösungskonzept berücksichtigt oder erfüllt (in der Entwicklung und im Betrieb)?

    • Wie wird das Schadenspotenzial oder die Eintrittswahrscheinlichkeit der Risiken vom Lösungskonzept minimiert?

    • Welche weiteren Maßnahmen sind empfohlen

4.2 Projektsteuerung und Management

Mögliche Fragen oder Inhalte:

• Soll es Status- oder Lenkungsmeetings soll es geben?

• Was soll kommuniziert werden?

• Wie und wo (Tool) soll die Projektsteuerung und Dokumentation erfolgen?

• Wie und über welche Kanäle sollen Status-Updates und der Austausch mit Stakeholdern erfolgen?

• Sollen bestimmte Vorgehensmodelle zur Projektdurchführung berücksichtigt werden (z. B. agiles Vorgehensmodell nach Scrum)?

• (…)

4.3 Lieferumfang

Mögliche Fragen oder Inhalte:

• Was ist explizit außerhalb des Projektes?

• Was wird von “anderen” umgesetzt?

• (…)

4.4 Arbeitspakete und Aufwandsschätzung

Bei den Arbeitspaketen handelt es sich im Grunde um eine vereinfachte Form eines Projektstrukturplans (PSP). Dabei sollten nach Möglichkeit auch immer Abnahmekriterien direkt mit definiert werden.

• (…)

4.5 Zeitplan und Meilensteine

Häufig plane ich die Meilensteine so, dass diese gleichzeitig den Arbeitspaketen entsprechen. Damit liefert man zu jedem Meilenstein (nach agilem Vorbild) direkt ein „Inkrement“ und kann die Zeitplanung auch leichter in Sprints organisieren. Dies ist jedoch immer individuell.

• (…)

4.6 Ressourcen und Technologien

Eine Auflistung der für das Lösungskonzept / Entwicklung benötigten Technologien und Lizenzen.

• (…)

5. MLOps (Schritte nach dem Projekt)

Umfasst alle Support-, Monitoring oder Wartungsvereinbarungen im Rahmen von MLOps, welche nach einer erfolgreichen Entwicklung und Inbetriebnahme zu erbringen sind sowie mögliche nächste Schritte. Ein Wichtiger Punkt, welcher gerne etwas „stiefmütterlich“ behandelt wird und einen Ausblick geben soll, wie die nächsten Schritte nach einem erfolgreichen Projekt aussehen können.

6. Vertragsbedingungen

Häufig macht es Sinn bestimmte Vertragsbedingungen, Ausschlüsse oder andere rechtliche Punkte gesondert zu dokumentieren.

7. Sonstige Punkte

Nicht selten ist es der Fall, dass Punkte noch offen sind oder aufkommen, welche zum Zeitpunkt der Angebotserstellung nicht beantwortet werden konnten.

8. Anhang

• (…)