Verstehen / Synthese /

Proto-Problem Statement

In einem Proto-Problem Statement identifiziert ein Team zu Beginn eines Projektes, welche Probleme zu überwinden sind, welche Akteure von den Problemen und ihren Lösungen betroffen ist und welche Randbedingungen hierbei zu berücksichtigen sind. Das Proto-Problem Statement steckt den Projektrahmen ab.

Einordnung

Das Proto-Problem Statement beschreibt den Startpunkt eines Projektes. Es hilft die Lücke zwischen einem Ist-Zustand und einem intendierten Soll-Zustand zu definieren, in dem es die zu überwindenden Probleme des Ist-Zustandes beschreibt.
Zu Beginn des Projektes stellen die Inhalte eines Proto-Problem Statements zunächst Annahmen dar (daher auch das "Proto" in der Bezeichnung). Im Verlauf der Verstehen-Phase wird das Bild des Proto-Problem Statements zunehmend geschärft und gegebenenfalls auch revidiert. Als Ergebnis resultiert ein überarbeitetes Problem Statement.

Das Problem Statement in Form einer aus Karten bestehenden Map ist für die Arbeit in einer Gruppe hilfreich. Karten können jederzeit geändert, zugefügt oder auch weggenommen werden. Zudem lässt sich die Map um relevante Aspekte wie Metriken, Risiken, Stakeholder und Randbedingungen erweitern.

Abbildung: Beispiel eines Proto-Problem Statement.

Erläuterungen

  • In der Spalte “Nutzende” werden betroffene Nutzergruppen angegeben. Diese können durch die Erstellung von Proto-Personas detailliert werden.
  • In der Spalte “Probleme" werden die größten (bekannten) Probleme angegeben, die mit einem Projekt adressiert werden sollen. Diese Probleme können das Unternehmen selbst, Kunden oder Nutzende betreffen. Mit Hilfe einer Proto-Journey können die Probleme von Nutzenden detailliert und bestimmten Abläufen und Schritten zugeordnet werden.
  • In der Spalte Lösungsansätze werden zunächst Erwartungen festgehalten. Die eigentlichen Lösungsansätze gilt es während der Projektlaufzeit zu erarbeiten. Zu Beginn kann es jedoch hilfreich sein, bestehende Lösungsideen in Erfahrung zu bringen.
  • In der Spalte Metriken wird angegeben, wie sich der Erfolg eines Projektes feststellen lässt. Die Auftstellung von Metriken erlaubt es, Erwartungen an ein Projektergebnis zu klären und objektiviert die Vorstellung der Auftraggeberin. Metriken können in einem Metriken-Board weiter detailliert werden.
  • Stakeholder sind Anspruchsgruppen, die von einem Problem, bzw. von dessen Lösung direkt oder indirekt betroffen sind. Sie sollten involviert oder zumindest regelmäßig über Zwischenergebnisse des Projektes informiert werden. Stakeholder können mit Hilfe einer Stakeholder-Analyse genauer untersucht werden.
  • Risiken können sich auf das Projekt selbst beziehen (ein Risiko, dass die Projektziele nicht erreicht werden können) oder aber auf das zu entwickelnde Produkt und die zu entwickelnde Dienstleistung (ein Risiko, das sich bei der Nutzung des zukünftigen Produktes/Service einstellt). Beide Kategorien, Projekt- und Produkt-/Service-Risiken, sind relevant und könneeiner Risiko-Analyse genauer beleuchtet werden.

Abbildung: Ein Proto-Problem Statement wird durch allfällige zusätzliche Artefakte ergänzt

Erarbeitung

Für die Erstellung der Map werden Auftraggeberin, das Projektteam und gegebenenfalls weitere bedeutsame Stakeholder eingeladen.

  • Die Titelzeile der Map wird vorbereitet. Die einzelnen Kategorien und das weitere Vorgehen wird erläutert. Es wird explizit erwähnt, dass es sich hier um Annahmen handelt.
  • In der Praxis hat es sich bewährt, wenn die Auftraggeberin als erste damit beginnt, Karten zu dem Problem Statement hinzuzufügen und ihren Inhalt kurz vorzustellen.
  • Das Team stellt kritische Fragen. Das Ergebnis wird diskutiert und gegebenenfalls angepasst.
  • Die Annahmen hinter den Karteninhalten werden identifiziert.

Erfahren Sie mehr ...

Proto-Personas

Eine Proto-Persona beschreibt einen hypothetischen, »archetypischen« User.

Artikel lesen

Proto-Journeys

Eine Proto-Journey beschreibt einen hypothetischen Ablauf zur Erreichung eines der Ziele einer Proto-Persona.

Artikel lesen

Stakeholder-Map

Stakeholder sind Anspruchsgruppen, die von einer Lösung direkt oder indirekt betroffen sind.

Artikel lesen

Annahmen-Map

In einer Annahmen-Map können identifizierte Annahmen auf deren Kritikalität priorisiert werden.

Artikel lesen