Skip to main content
Key Takeaways

Definition: Eine Problemstellung beschreibt klar die Lücke zwischen aktuellem Zustand und gewünschtem Ergebnis in einem Projekt.

Fokus: Die Formulierung einer Problemstellung hält Projekte auf Kurs, verhindert Scope Creep und unterstützt bei Entscheidungen.

Komponenten: Wichtige Elemente einer Problemstellung sind Problem-Beschreibung, Kontext, Auswirkungen und Zielsetzungen.

Vergleich: Problemstellungen unterscheiden sich von Projektauftrag, Business Case, Hypothesen und Projektumfang.

Fehler: Vermeiden Sie Komplexität, Unklarheit, verfrühte Lösungen, das Ignorieren von Stakeholdern und das Verwechseln von Symptomen mit Ursachen.

Eine Problemdefinition für ein Projekt beschreibt die Kluft zwischen dem aktuellen Zustand und dem gewünschten Ergebnis, damit sich alle Teammitglieder abstimmen können, bevor Lösungen, Budgets und Zeitpläne den Ton angeben. Ich habe erlebt, wie Projekte Wochen verlieren, weil Stakeholder unterschiedliche Versionen desselben Problems lösen wollten oder die Formulierung gezielt auf eine bevorzugte Lösung gelenkt wurde.

Diese Anleitung hilft Ihnen, eine fokussierte und faktenbasierte Problemdefinition zu schreiben, typische Fehler zu vermeiden, ein praxistaugliches Template zu verwenden und anhand von Beispielen aus realen Projekten zu lernen.

Was ist eine Problemdefinition für ein Projekt?

Eine Problemdefinition ist eine klare, präzise Beschreibung einer Fragestellung, die Ihr Projekt adressieren soll. Sie benennt eine spezifische Kluft, einen Schmerzpunkt oder ein nicht erfülltes Bedürfnis und erklärt, warum dies relevant ist. Sehen Sie sie als das "Warum" hinter allem, was Ihr Projekt tun wird.

Unlock for Free

Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.

Step 1 of 2

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Eine gute Problemdefinition sorgt dafür, dass sich Ihr Team auf ein gemeinsames Verständnis des Problems ausrichtet. Sie legt die Grenzen der Arbeit fest, rechtfertigt die angeforderten Ressourcen und gibt den Stakeholdern einen Grund, sich zu engagieren.

Eine überzeugende Problemdefinition weist einige Schlüsselkriterien auf:

  • Speziell: Sie benennt das exakte Problem, nicht eine vage Problemkategorie.
  • Messbar: Sie bezieht sich nach Möglichkeit auf Daten, Kennzahlen oder beobachtbare Ergebnisse.
  • Kontextbezogen: Sie beschreibt, wo und wann das Problem auftritt.
  • Neutral gegenüber Lösungen: Sie beschreibt das Problem, ohne eine Lösung vorwegzunehmen.
  • Stakeholder-bewusst: Sie macht deutlich, wer betroffen ist und wie.

Warum eine Problemdefinition für ein Projekt schreiben?

Hier sind einige wichtige Gründe, warum Sie für Ihr Projekt eine Problemdefinition erstellen sollten:

  • Sie hält das Projekt auf Kurs: Eine Problemdefinition dient als Leitplanke für Ihr gesamtes Projekt. Wenn neue Anforderungen auftauchen, können Sie immer auf die Definition verweisen und fragen, ob sie dazu beiträgt, das Problem zu lösen. Das verhindert eine schleichende Ausweitung des Projektumfangs, schärft Entscheidungen und schafft klare Verantwortlichkeit. Projekte ohne schriftliche Problemdefinition kommen häufiger ins Stocken.
  • Sie leitet Forschung und Innovation: Die Problemdefinition gibt die Fragestellung vor, nach der Sie forschen, lenkt die Methodik und unterstützt die Entwicklung überprüfbarer Hypothesen. Sie verankert Kreativprozesse in den Problemen der Nutzer anstatt in abstrakten Ideen. Ich habe gesehen, wie Teams deutlich bessere Lösungen fanden, wenn sie mehr Zeit auf die Problemanalyse verwendeten.
  • Sie schafft Vertrauen bei den Stakeholdern: Beteiligte möchten wissen, dass ihre Investition einem echten Bedürfnis zugutekommt. Eine Problemdefinition schafft Transparenz und gemeinsames Verständnis. Sie erleichtert die Freigabe, da die Prüfer das Problem, dessen Auswirkungen und Dringlichkeit sehen. Außerdem werden Erfolgskriterien von Anfang an definiert.

Wichtige Bestandteile einer Problemdefinition

Jede überzeugende Problemdefinition umfasst diese vier Elemente:

Problembeschreibung

Dies ist der Kern Ihrer Definition. Benennen Sie, was passiert – oder nicht passiert –, das anders sein sollte. Seien Sie direkt und konkret. "Das Kunden-Onboarding dauert zu lange" ist ein Anfang, aber "Neue Unternehmenskunden warten im Durchschnitt 23 Tage auf den Abschluss des Onboardings, während der Branchenstandard bei 10 Tagen liegt" ist deutlich besser. 

Hintergrund und Kontext

Erklären Sie, warum dieses Problem existiert und welche Umstände es begleiten. Vermitteln Sie den notwendigen Hintergrund, damit die Lesenden die Lage verstehen. Nehmen Sie Geschichte, Rahmenbedingungen oder organisatorische Einschränkungen auf. Im Beispiel kann die Onboarding-Verzögerung etwa entstehen, weil der Prozess immer noch auf manueller Dateneingabe in isolierten Systemen basiert. 

Auswirkung und Relevanz

Beschreiben Sie, wen das Problem betrifft und was passiert, wenn es ungelöst bleibt. Quantifizieren Sie die Folgen wann immer möglich.

Entgangene Einnahmen, verschwendete Arbeitsstunden, sinkende Kundenzufriedenheit oder verpasste Fristen sind allesamt messbare Folgen. Dieser Abschnitt beantwortet die Frage, die jeder Stakeholder stellt: "Warum sollten wir uns gerade jetzt darum kümmern?"

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join. <br><br>

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Ziele oder angestrebte Ausrichtung

Beschreiben Sie den idealen Zielzustand. Wie sieht es aus, wenn das Problem gelöst ist? Dies ist keine vollständige Lösung, sondern eine Richtungsangabe, die aufzeigt, wohin Sie steuern.

Im Onboarding-Beispiel könnte das Ziel lauten: "Die durchschnittliche Onboarding-Zeit innerhalb von sechs Monaten auf zehn Tage oder weniger reduzieren." Diese Aussage gibt dem Projekt eine Zielmarke, ohne den präzisen Lösungsweg festzulegen.

Wie schreibt man eine Problemdefinition für ein Projekt?

Der folgende Schritt-für-Schritt-Prozess beschreibt, wie man von Grund auf eine effektive Problemstellung formuliert.

1. Identifizieren und Beschreiben des Problems

Beginnen Sie mit der Beobachtung. Sammeln Sie Daten, werten Sie Kundenfeedback aus, sprechen Sie mit Mitarbeitenden an der Basis und führen Sie Interviews mit Stakeholdern. Ihr Ziel ist es, das Problem konkret zu benennen, nicht es aus dem Konferenzraum heraus zu erraten. Die besten Problemstellungen kommen von den Personen, die dem Problem am nächsten sind.

2. Stellen Sie die richtigen Fragen

Nachdem Sie das Problem identifiziert haben, überprüfen Sie es mit gezielten Fragen:

  • Wer ist von diesem Problem betroffen?
  • Wo und wann tritt es auf?
  • Was ist die Lücke zwischen dem aktuellen Zustand und dem gewünschten Zustand?
  • Warum ist es gerade jetzt relevant?

Diese Fragen zwingen Sie dazu, von einer allgemeinen Beschwerde zu einer präzisen Beschreibung überzugehen. Wenn Sie sie nicht klar beantworten können, benötigen Sie mehr Informationen, bevor Sie etwas schreiben.

3. Analysieren Sie das Problem gründlich

Nutzen Sie Methoden der Ursachenanalyse, um zu verstehen, was das Problem tatsächlich antreibt. Die 5-Why-Methode eignet sich hier besonders gut.

Nehmen Sie das Beispiel Onboarding von zuvor. Sie starten mit dem Symptom und fragen immer wieder nach dem Warum:

  1. Warum dauert das Onboarding 23 Tage? Weil Kundendaten in drei separate Systeme eingetragen werden müssen.
  2. Warum sind drei unterschiedliche Systeme notwendig? Weil CRM, Abrechnungsplattform und Bereitstellungstool unabhängig voneinander angeschafft und nie integriert wurden.
  3. Warum wurden sie nie integriert? Weil jede Abteilung ihr eigenes Tool nach eigenen Anforderungen ausgewählt hat.
  4. Warum hat jede Abteilung eigenständig Tools ausgewählt? Weil es keine bereichsübergreifende Kontrolle beim Technikeinkauf gab.
  5. Warum gab es keine bereichsübergreifende Kontrolle? Weil das Unternehmen schneller gewachsen ist als seine Governance-Prozesse.

Nach der fünften Frage sind Sie von „Onboarding dauert zu lange“ zu einem strukturellen Governance-Problem gelangt. Das verändert den Ansatz für das Projekt grundsätzlich. So kann Ihre Problemstellung jetzt die eigentliche Ursache und nicht nur das Symptom berücksichtigen, was sie deutlich hilfreicher macht.

galen low headshot

Author's Tip

Ein Fischgrätendiagramm ist ein weiteres nützliches Werkzeug, besonders wenn das Problem mehrere beitragende Faktoren in den Bereichen Menschen, Prozesse, Technologie und Richtlinien hat. Ordnen Sie in jeder Kategorie mögliche Ursachen zu und suchen Sie nach Schwerpunkten. Das Ziel bleibt: Bevor Sie eine Aussage formulieren, dringen Sie unter die Oberfläche vor.

4. Formulieren Sie die Problemstellung

Nutzen Sie diese Vorlage als Ausgangspunkt:

[Stakeholder-Gruppe] erlebt [Problem] im [Kontext], was zu [Auswirkung] führt. Dieses Projekt zielt darauf ab, [Zielsetzung] zu erreichen.

Zum Beispiel: „Neue Unternehmenskunden erleben im Durchschnitt einen 23-tägigen Onboarding-Prozess über drei nicht verbundene Systeme, was zu einem Drop-off von 40 % vor der vollständigen Aktivierung führt. Dieses Projekt hat zum Ziel, die Onboarding-Zeit innerhalb von sechs Monaten auf zehn Tage oder weniger zu reduzieren.“

Ihr erster Entwurf muss nicht perfekt sein. Konzentrieren Sie sich darauf, das Problem, den Kontext, die Auswirkung und das Ziel zu erfassen. Streichen Sie dann alles, was keinen Mehrwert bietet.

galen low headshot

Author's Tip

Die meisten Problemstellungen sollten zwischen ein und drei Sätzen umfassen. Wenn Ihre länger als zwei Sätze ist, prüfen Sie genau, ob Sie tatsächlich ein oder zwei Probleme beschreiben. Nach meiner Erfahrung werden kürzere Aussagen gelesen, verstanden und wirklich von Teams genutzt.

5. Prüfen und Überarbeiten

Lesen Sie den Entwurf laut vor. Achten Sie auf Klarheit, Kürze und Präzision. Entfernen Sie jeglichen Jargon, den Außenstehende nicht verstehen würden. Achten Sie darauf, dass die Aussage lösungsneutral bleibt. Wenn darin steht „wir müssen X umsetzen“, ist das eine Lösung, kein Problem. Konzentrieren Sie sich auf das eigentliche Thema.

6. Validierung mit Stakeholdern

Teilen Sie den Entwurf mit den Personen, die dem Problem am nächsten stehen, sowie mit denjenigen, die das Projekt finanzieren oder genehmigen werden. Berücksichtigen Sie deren Rückmeldungen, bevor Sie das Dokument finalisieren.

Dieser Schritt klingt einfach, ist aber häufig der Punkt, an dem Problemstellungen entweder gestärkt oder zusammenbrechen. So gehen Sie mit zwei häufigen Problemen um:

  • Zwei Stakeholder sind uneinig über das Problem: Widerstehen Sie der Versuchung, beide Sichtweisen in einer schwammigen Aussage zu vermischen. Betrachten Sie die Uneinigkeit als ein Signal dafür, dass Sie mehr Daten benötigen. Oft beschreiben beide Parteien Symptome eines tieferliegenden Problems, das keiner von beiden vollständig benennen kann. Kehren Sie zu den 5-Whys zurück.
  • Die Leitung will, dass die Aussage ihre Lösung rechtfertigt: Am wirkungsvollsten ist es aus meiner Erfahrung, zu fragen: „Welche Beweise müssten vorliegen, damit diese Lösung korrekt ist?“ Formulieren Sie die Problemstellung anhand dieser Belege. Falls die Beweise existieren, weist die Aussage in Richtung ihrer Lösung. Andernfalls führen Sie eine Diskussion über Annahmen.

Validierung bedeutet nicht, Zustimmung und Konsens um jeden Preis zu erreichen. Es geht darum, sicherzustellen, dass die Aussage korrekt ist – nicht einfach nur angenehm.

Beispiele für Problemstellungen in Projekten

Hier sind fünf Beispiel-Problemstellungen aus unterschiedlichen Branchen. Beachten Sie, wie jede einzelne ihre Nachweise und Formulierungen an die Standards ihres jeweiligen Bereichs anpasst.

IT und Softwareentwicklung

Beispiel für eine Problemstellung: Kundendienstmitarbeitende nutzen derzeit drei verschiedene Tools, um ein einzelnes Ticket zu bearbeiten, was zu einer durchschnittlichen Bearbeitungszeit von 14 Minuten pro Anfrage führt. Der Branchendurchschnitt liegt bei 7 Minuten. Mit diesem Projekt soll die Bearbeitungszeit durch die Zusammenführung der Supportprozesse auf eine Plattform reduziert werden.

Dies ist typisch für IT-Problemstellungen. Sie basiert auf betrieblichen Kennzahlen und Benchmarking-Daten. Ein agiles Team könnte dies noch weiter reduzieren und als Sprintziel in einen einzigen Satz fassen.

Gesundheitswesen und öffentliche Gesundheit

Beispiel für eine Problemstellung: Patienten in ländlichen Gebieten der Drei-Landkreis-Region müssen im Durchschnitt 45 Meilen fahren, um Facharztversorgung zu erhalten, was zu einer 38%-Nicht-Erscheinen-Quote bei Folgeterminen führt. Ziel des Projekts ist es, diese Quote auf unter 15% zu senken, indem der Zugang zu Fernkonsultationen ausgebaut wird.

Problemstellungen im Gesundheitswesen müssen für die Prüfung durch Aufsichtsbehörden und Fördergremien geeignet sein. Handelt es sich um einen Fördermittelantrag, würden Sie zusätzlich Literaturangaben zu veröffentlichten Studien über Transportprobleme und gesundheitliche Ergebnisse hinzufügen.

Bildungswesen

Beispiel für eine Problemstellung: Erstakademiker an der Universität brechen mit einer um 22% höheren Quote ab als ihre Kommilitonen, meist im zweiten Semester. Bei dieser Gruppe finden durchschnittlich 0,8 Beratungsgespräche pro Semester statt, verglichen mit 2,4 Sitzungen bei Studierenden aus Akademikerfamilien. Ziel dieses Projekts ist es, diese Beratungslücke zu schließen und die Wiedereinschreibung im zweiten Semester zu erhöhen.

Problemstellungen im Bildungsbereich profitieren von aufgeschlüsselten Daten. Die Benennung der spezifischen Zielgruppe und des Semesters macht das Ganze umsetzbar.

Geschäftsprozesse und Prozessoptimierung

Beispiel für eine Problemstellung: Der monatliche Abschlussprozess dauert im Finanzteam durchschnittlich 12 Werktage und beansprucht pro Zyklus über 400 Personalstunden. Fehler, die während der Abstimmung entdeckt werden, verursachen 35% dieses Zeitaufwands. Mit diesem Projekt soll der Abschlusszyklus auf 7 Werktage reduziert werden, indem die Grundursachen der Fehler adressiert werden.

Gemeinnützige Organisationen und Kommunalwesen

Beispiel für eine Problemstellung: Nahrungsmittelunsichere Haushalte im Innenstadtbereich haben nur einen Supermarkt im Umkreis von zwei Meilen und 60% der Bewohner verfügen über kein Transportmittel. Die Besuche in Notfall-Ausgabestellen für Lebensmittel sind jährlich um 40% gestiegen. Dieses Projekt zielt darauf ab, die Lebensmittelverteilung auszubauen und die Entfernung zu frischen Nahrungsquellen zu verkürzen.

Problemstellungen im gemeinnützigen Bereich dienen häufig auch als Argument in der Mittelbeschaffung. Die hier ausgewählten Daten sollen Dringlichkeit erzeugen. Ein Corporate-Operations-Team würde Transportfragen nicht erwähnen, aber für einen Förderer in der Gemeinschaft macht dieses Detail das Problem greifbar und die Investition nachvollziehbar.

Problemstellung vs. andere Projektdokumente

Eine Problemstellung wird häufig mit anderen Projektdokumenten verwechselt. So unterscheiden sie sich.

DokumentZweckZentraler Unterschied zur Problembeschreibung
ProblembeschreibungDefiniert das spezifische Problem, das das Projekt adressiertKonzentriert sich ausschließlich auf das Problem und dessen Auswirkungen
ProjektauftragGenehmigt das Projekt und skizziert Umfang, Meilensteine und BudgetUmfassenderes Dokument; die Problembeschreibung fließt darin ein
Business CaseBegründet die Investition durch Kosten-Nutzen-VergleichFokussiert auf finanzielle und strategische Rechtfertigung
HypotheseStellt eine prüfbare Erklärung oder Prognose aufBietet eine potenzielle Antwort; die Problembeschreibung definiert die Frage
ProjektumfangDefiniert die Grenzen der auszuführenden ArbeitBeschreibt, was getan wird; die Problembeschreibung erklärt, warum

Problembeschreibung vs. Projektauftrag

Die Problembeschreibung fließt in den Projektauftrag ein, aber der Auftrag ist ein umfassenderes Dokument. Ein Projektauftrag enthält den Projektumfang, Meilensteine, Budget, die wichtigsten Interessengruppen und Erfolgskriterien.

Die Problembeschreibung liefert das „Warum“, das all diese anderen Elemente verankert. Schreiben Sie die Problembeschreibung zuerst und nutzen Sie sie dann als Grundlage für den Projektauftrag.

Problembeschreibung vs. Business Case

Ein Business Case begründet die Investition. Er vergleicht Kosten, Nutzen, Risiken und Alternativen, um einen finanziellen oder strategischen Nutzen zu belegen. Die Problembeschreibung definiert den Schmerzpunkt, auf dem der Business Case aufbaut.

Wenn Sie das Problem nicht klar artikulieren können, fehlt Ihrem Business Case eine überzeugende Grundlage. Schreiben Sie die Problembeschreibung, bevor Sie den Business Case erstellen.

Problembeschreibung vs. Hypothese

Eine Hypothese schlägt eine überprüfbare Antwort auf eine Frage vor. Eine Problembeschreibung definiert die Frage selbst. Bei Forschungsprojekten formulieren Sie zuerst die Problembeschreibung und leiten daraus eine oder mehrere Hypothesen ab.

Beide arbeiten zusammen, erfüllen aber unterschiedliche Zwecke. Sie zu vermischen führt zu Problembeschreibungen, die vorschnell zu Schlussfolgerungen kommen, bevor die eigentliche Untersuchung begonnen hat.

Problembeschreibung vs. Projektumfang

Der Projektumfang definiert die Grenzen der Arbeit, die Ihr Team abliefern wird. Er beantwortet die Frage: „Was machen wir – und was nicht?“ Die Problembeschreibung erklärt hingegen: „Warum ist diese Arbeit wichtig?“ Ein Umfang ohne Problembeschreibung kann beliebig wirken.

Eine Problembeschreibung ohne Umfang kann offen und ziellos erscheinen. Sie brauchen beides – die Problembeschreibung sollte jedoch zuerst stehen.

Häufige Fehler beim Formulieren von Problembeschreibungen

Hier sind einige häufige Stolperfallen, die Sie bei der Erstellung Ihrer Problembeschreibung vermeiden sollten:

  • Die Formulierung überkomplizieren: Widerstehen Sie dem Drang, jeden verwandten Aspekt in eine einzelne Aussage zu packen. Wenn Ihre Problembeschreibung ein Glossar benötigt, ist sie zu komplex. Bleiben Sie bei einem spezifischen Problem. Verwenden Sie eine Sprache, die jeder beim ersten Lesen versteht.
  • Zu vage oder allgemein bleiben: „Unsere Kunden sind unzufrieden“ liefert niemandem ausreichend Informationen zum Handeln. Eine nützliche Problembeschreibung gibt an, wer betroffen ist, worin das Problem besteht, wo und wann es auftritt und wie die Lücke aussieht. 
  • Vorschnell Lösungen vorschlagen: Häufig rutscht die Lösung nicht versehentlich hinein. Jemand mit Entscheidungsbefugnis hat schon festgelegt, was gebaut oder gekauft werden soll, und die Problembeschreibung wird im Nachhinein als Rechtfertigung benutzt. 
  • Die Auswirkungen auf Stakeholder ignorieren: Eine Problembeschreibung, die nicht benennt, wer betroffen ist, wirkt abstrakt. Identifizieren Sie immer die Personen oder Gruppen mit dem Problem und beschreiben Sie die Konsequenzen für sie.
  • Validierung überspringen: Eine Problembeschreibung im stillen Kämmerlein zu schreiben ist riskant. Die Menschen, die dem Problem am nächsten sind, werden Dinge bemerken, die Ihnen entgehen. Die Projektentscheider wollen ihre Perspektive wiederfinden. Teilen Sie Ihren Entwurf frühzeitig, holen Sie Feedback ein und überarbeiten Sie ihn.
  • Symptome mit Ursachen verwechseln: Symptome fallen zuerst auf. Die eigentlichen Ursachen liegen tiefer. „Die Mitarbeiterfluktuation ist hoch“ ist ein Symptom. „Neue Mitarbeitende bekommen keine strukturierte Einarbeitung, was nach 90 Tagen zu Desinteresse führt“ kommt näher an die Ursache heran. Wenn Ihre Problembeschreibung nur Symptome nennt, werden Sie wahrscheinlich das falsche Problem angehen.

Wie geht es weiter?

Die erfolgreichsten Projekte starten mit klaren Gedanken, praktischen Werkzeugen und bewährten Methoden. Melden Sie sich für ein kostenloses DPM-Mitgliedskonto an und erhalten Sie Zugang zu Vorlagen, Ressourcen und Expertenwissen, damit Sie Projekte souverän führen können.