Die Problem-Ziel-Beschreibung – Ist & Soll exakt definieren

Als Projektleiter, Manager oder Analyst bzw. deren Berater bist Du mit folgenden Fragen konfrontiert:

• Mit welchen Problemen sind wir konfrontiert und welche Ziele wollen wir erreichen?
• Was hilft uns in der Vorklärungsphase eines Projektes?
• Womit schaffen wir ein gemeinsames Verständnis zum Ist- und Ziel-Zustand?

Unterstützung findest Du in der Problem-Ziel-Beschreibung und der systematischen Problem-Ziel-Analyse.

---

Ergebnis: Definition von Ist- und Zielzustand, Scope, Stakeholdern und Messkriterien

Teilnehmer: mind. 2 (Auftraggeber und -nehmer)

Dauer: 10-30 Minuten (je Problem bzw. Ziel und Stakeholder)

Utensilien: Whiteboard/Flipchart und Stifte oder Notebook mit Office Software

Zweck

Mit einer Problem-Ziel-Beschreibung definierst Du das Problem, grenzt es ab, präzisiert einen Ziel-Zustand und erklärst, unter welchen Bedingungen und Annahmen dieser erreicht werden kann. Die Technik gibt Dir Struktur beim Start einer Initiative.

Statt sofort in die Beschreibung des Vorhabens mittels eines Projektsteckbrief oder gar einem Projektauftrag zu gehen, beschäftigst Du Dich zunächst mit dem (negativen) Ist- und dem (positiven) Soll-Zustand.

Auf einer einzigen Seite definierst Du die Defizite und Bedarfe, ohne Dich mit dem Weg zwischen diesen beiden Zuständen auseinanderzusetzen. Das sorgt für Klarheit, was eigentlich weshalb erreicht werden soll.

---

Aufbau

Problem-Ziel-Beschreibung – „Wo stehen wir und was wollen wir erreichen?“

Eine gute Problem-Ziel-Beschreibung enthält genau sieben Bestandteile. Im Optimum passen diese auf eine DIN-A4-Seite bzw. Präsentationsfolie.

Ergänze den Einseiter mit einer Überschrift. Diese enthält das Ziel in einem prägnanten Satz. Des Weiteren notierst Du als Meta-Informationen die Autoren sowie das Datum der letzten Änderung.

Problembeschreibung – „Wo stehen wir?“

In diesem ersten Abschnitt präzisierst Du das Grundproblem in mehreren Sätze. Du beschreibst die aktuelle negative Situation mit klaren Worten. Je spezifischer, wohldefinierter und messbarer desto besser.

• Mit welchen Schwierigkeiten hat mein Auftraggeber zu kämpfen?
• Welche Entwicklungen erschweren die Zielerreichung?
• Was hindert uns konkret am Vorankommen?
• Welche Dinge machen die Wettbewerber besser?

Vermeide ein Vorwegnehmen einer Lösung durch Begriffe wie ‚Mangel an…‘, ‚inadäquat‘, ‚ungenügend‘, ‚unangemessen‘ oder ‚fehlend‘ sowie persönliche Meinungen und Kritiken.

Subjektive Bewertungen und mehrdeutige Begriffe sind ebenfalls fehl am Platz. Spare ebenfalls schwammige und mehrdeutige Aussagen aus. Nutze für weitere Detaillierung die Problembeschreibung bzw. Problemskizze.

Zielbeschreibung – „Wohin wollen wir?“

Abgleitet vom Problem spezifizierst Du hier das Ziel. Definiere dieses möglichst SMART, daher spezifisch, messbar, attraktiv und realistisch.

• Welcher Zielzustand soll angestrebt werden?
• Welche Fragen müssen beantwortet werden?
• Wir gehen nach dem Projekt durch das Unternehmen: Was hat sich positiv gewandelt?
• Wie lautet der neue Auftrag?

Formuliere positiv und erstrebenswert mit einfachen und verständlichen Worten. Unterscheide zwischen Unternehmens-, Projekt- und Auftraggeberzielen. Unter Nicht immer sind diese nicht kongruent, stehen vielleicht sogar in Konflikt. Das Zieldiagramm schafft weitere Klarheit.

Scope – „Was betrachten wir?“

Nun klärst Du den Umfang und die Detailtiefe des Problems- und Lösungsbereichs auf fachlicher und technischer Ebene. Gerne kannst Du dazu Kreativtechniken wie das Brainstorming bzw. 6-3-5 Methode oder – bei Produktweiterentwicklungen – SCAMPER heranziehen.

• Welche Fachbereiche sind Teil des Problems, welche Teil der Lösung?
• Welche Standorte sind im Scope, welche nicht?
• Welche Informationen zahlen auf das Problemverständnis ein? Welche auf die Lösungsfindung?
• Welcher Zeitraum wird betrachtet?

Das Scoping ist sehr wichtig. Manchmal hilft es, explizit aufzuzählen, was nicht im Scope ist, also außerhalb des Betrachtungsbereiches liegt. Mit einer Ist-Ist-Nicht-Analyse schaffst Du Klarheit.

Stakeholder – „Wer ist betroffen oder beeinflusst das Problem bzw. Ziel?“

In diesem Abschnitt hältst Du die betroffenen und einzubindenden Personen, Teams, Bereiche und Gremien sowie ihre Interessen fest.

• Wer hat das Problem, ist also der Problem Owner? Wer ist Teil der Lösung?
• Mit wem muss aus inhaltlichen oder politischen Gründen auf jeden Fall gesprochen werden?
• Wer finanziert die Umsetzung zur Zielerreichung?
• Wer hat von den beteiligten Gruppen die Entscheidungsgewalt?

Gehe an dieser Stelle nicht zu tief in die Stakeholderanalyse. Wichtig ist ein erster Überblick über die wesentlichen Mitspieler.

Annahmen – „Wovon gehen wir aus?“

Meist kann ein Ziel nur erreicht werden, wenn bestimmte Annahmen zutreffen. Definiere diese in diesem Abschnitt.

• Was sind die Voraussetzungen für ein Gelingen?
• Worin bestehen die Erfolgsfaktoren?
• Welche Parameter sind als gegeben anzusehen?
• Von welcher Problemursache ist auf jeden Fall auszugehen?

Vermeide pauschale Annahmen wie ‚ein stringentes Projektmanagement‘ oder ‚klare Kommunikation‘. Diese passen für fast jede Problem-Ziel-Beschreibung. Gerne kannst Du die Hauptannahme später in das RAID Log übernehmen

Randbedingungen – „Was sehen wir als gegeben an?“

An dieser Stelle formulierst Du technische, organisatorische, rechtliche, wirtschaftliche etc.  Einschränkungen, sowohl für den Ziel-Zustand als auch den Lösungsweg.

• Welche Budget-Obergrenze gilt?
• Welcher Zeitrahmen ist einzuhalten?
• Welche Kundensegmente sind nicht zu ignorieren?
• Was ist in jedem Fall (nicht) Teil der Lösung?

Erneut gilt: Konzentriere Dich insbesondere auf den Ziel-Zustand und nicht auf den Weg (das Projekt) dorthin. Mit Randbedingungen zum Vorgehen wirst Du Dich später in der Projektplanung noch ausführlich beschäftigen.

Entscheidungskriterien (optional) – „Womit bewerten wir die Zielerreichung?“

Schließlich hältst Du weitere messbare Parameter fest, anhand derer die Lösung bzw. ihre Zwischenschritte bewertet werden können. Gerade bei einer phasenweisen Entscheidung für oder gegen die Weiterverfolgung einer Lösung ist dieser optionale Abschnitt wichtig.

• Für welchen Zeitpunkt sollen 5 Prozent Marktanteil angepeilt werden?
• Welche Nutzerzahlen soll nächstes Jahr erreicht werden?
• Auf einer Skala von 1 (sehr unzufrieden) bis 10 (sehr zufrieden): Wie soll sich das Klima in der Abteilung gewandelt haben?
• An welchen Parametern würden der Projektsponsor merken, dass das Ziel erreicht worden ist?

Fixiere mit den Entscheidungskriterien, mit denen sich Erfolg bzw. Misserfolg einer (Teil-)Lösung festmachen lassen.

---

Anwendung

1. Beschreiben

Fülle in einem Durchgang am Stück alle Abschnitte der Problem-Ziel-Beschreibung, entweder allein, mit einem Partner oder im Team im Rahmen eines Problemdefinitions-Workshops.

Formuliere präzise, am besten in Spiegelstrichen mit atomaren Aussagen. Beschreibe, statt zu interpretieren.

• Was sind bloße Vermutungen, was konkrete Tatsachen?
• Wobei handelt es sich um eine persönliche Meinung, wobei um einen gesicherten Fakt?

2. Verfeinern

Iteriere mehrmals durch die Abschnitte der Problem-Ziel-Beschreibung. Nutze Tools wie die Five-Why Fragetechnik, das Ishikawa Diagramm oder den Issue Tree, um die wahre Ursache eines Problems aufzuspüren und die Symptome hinter Dir zu lassen.

Verwende das Zieldiagramm, um die Zusammenhänge zwischen Ziele und Stakeholder anschaulich zu visualisieren. Vermeide bei Diskussion im Team gezielt die gruppendynamischen Effekte. Nur weil alle davon reden, ist die eine Sache auch wirklich das zu lösende Problem.

3. Abstimmen

Lasse die dokumentierte Problem-Ziel-Beschreibung von allen Stakeholdern – insbesondere dem zukünftigen Auftraggeber – bestätigen. Das Dokument fungiert fortan als Input für das Projekt.

---

Beispiele

Problem-Ziel-Beschreibung für die Harmonisierung von Modellierungsansätzen

Untere Abbildung zeigt ein anonymisiertes Beispiel aus der Beratungspraxis. Ziel war es, die Modellierungsaktivitäten in den Fachbereichen Elektrik/Elektronik eines Technologieunternehmens zu harmonisieren.

---

Vor- & Nachteile

Pro

• Eine Problem-Ziel-Beschreibung räumt dem Problem bewusst physischen und zeitlichen Raum an. Sie zwingt Dich, Dein Team und den Auftraggeber, sich mit dem Status Quo zu beschäftigen.
• Gleichzeitig erlaubt die Methode den Soll-Zustand exakt zu erfassen. Nur wenn das Ziel beschrieben werden kann, kann es auch erreicht werden.
• Damit schafft die Problem-Ziel-Beschreibung früh ein gemeinsames Verständnis zwischen den Akteuren.

Contra

• Menschen setzen sich nicht gerne mit Problemen auseinander, sondern arbeiten viel lieber an den Lösungen.  Oft ist es nicht einfach diese Akteure dazu zu bewegen, zunächst das Problem genauer zu beschreiben und sich dann mit der Lösung auseinanderzusetzen.
• Die Problem-Ziel-Beschreibung betrachtet weder die Ursachen noch die Auswirkungen eines Problems. Nutze für die Ursachen Tools wie das Ishikawa Diagramm, den Issue Tree oder die Five-Why Fragetechnik.
• Große Probleme musst Du in viele kleine einzelne Probleme herunterbrechen und in eine sachlogische sowie zeitliche Abhängigkeit bringen. Die Methode unterstützt Dich hier leider nicht. Nutze hierzu besser die Problemskizze.

---

Praxistipps

Tipp 1 – Stakeholder eng in Erstellung einbeziehen

Jeder Stakeholder ist anders, besitzt individuelle Erfahrungen und persönliche Ziele. Als Konsequenz sieht nicht jeder das Problem und das Ziel gleich.

Agiere als Vermittler. Identifiziere dazu zunächst alle für die Problem-Ziel-Beschreibung relevanten Stakeholder. Hilfreiche Fragen an den Auftraggeber:

• Wer entscheidet noch über den Erfolg oder Misserfolg der Initiative?
• Wessen Ziele sollten wir ebenfalls berücksichtigen?
• Welche Stakeholder sind von den Zielen und Problemen positiv oder negativ betroffen?

Entwerfe dann allein und ungestört eine Erstfassung der Problem-Ziel-Beschreibung. Stelle diese dann den aufgedeckten Stakeholdern vor und lege damit die verschiedenen Sichtweisen auf das Problem und den Zielzustand offen. Schaffe auf Basis der Diskussionen ein gemeinsames Verständnis.

Tipp 2 – Zwischen Meinungen, Tatsachen und Vermutungen unterscheiden

Meinung ≠ Tatsache ≠ Vermutung. Differenziere bei der Problem-Ziel-Beschreibung strikt zwischen Meinung, Tatsache und Vermutung.

• Eine Meinung ist eine von individuellen Wertvorstellungen, Geschmack und/oder Gefühlen geprägte Einstellung eines Akteurs gegenüber einem bestimmten Gegenstand.
• Eine Tatsache ist ein ein wirklicher, nachweisbarer, bestehender, wahrer oder anerkannter Sachverhalt.
• Schließlich ist eine Vermutung eine Annahme, deren Gültigkeit zwar für möglich gehalten wird, die aber bisher nicht bewiesen bzw. validiert ist.

Tipp 3 – Für Projektbeschreibung weiterverwenden

Anders als zum Projektsteckbrief oder Projektauftrag erklärt eine Problem-Ziel-Beschreibung nicht, wie bei der Lösung vorgegangen werden soll. Stattdessen konzentriert sie sich auf den gegenwärtigen und den zukünftigen Zustand. Nutze das Tool als Input für eine Projektbeschreibung.

Tipp 4 – Wahre Probleme & Ziele finden

Regelmäßig ist eine spontan ins Felde geführte Aussage nicht automatisch ein echtes Problem bzw. echtes Ziel. Oder anders ausgedrückt: Was ein Kunde will, ist nicht immer dass, was er tatsächlich braucht.

Nutze Methoden wie die Five-Why Fragetechnik, die 6-W Fragetechnik, das Beziehungsdiagramm oder das Ishikawa Diagramm, um die wahren Schmerzen bzw. Wünsche zu identifizieren.

---

Ursprung

Der Ursprung der Methode ist mir nicht bekannt. Gerne Deine Hinweise per E-Mail an mich.

---

Bonusmaterial

Georg Jocham: Ausgangssituation und Zielsetzung. Vernachlässigt, unterschätzt und unglaublich wertvoll. (13,5 min) – Georg Jocham hebt im Audiocast die Relevanz einer guten Problem-Ziel-Beschreibung hervor

„Probleme werden zu Chancen, wenn die richtigen Leute zusammen sind.“

– Robert Redford, US-amerikanischer Schauspieler, Filmregisseur und Filmproduzent