Auf einen Blick
Mit Hilfe der MoSCow-Methode können Ziele und Anforderungen nach Must-, Should-, Could- und Would-Zielen priorisiert werden. Liegen klare Prioritäten vor, können Projektentscheidungen leichter getroffen und anhand der wichtigsten Ziele ausgerichtet werden.
Was hat es mit der MoSCow-Methode auf sich? Beginnen wir mit einem meiner liebsten Sprüche:
„Wenn alles wichtig ist, ist nichts wichtig.“
Diese Aussage wird oft im Zeitmanagement verwendet: Wenn du einen Berg von Aufgaben vor dir herschiebst, die alle gleich wichtig sind – wie sollst du dann auswählen? Hier kommt das Thema Priorisierung ins Spiel.
Gleiches gilt für Projektziele.
Ja: Es wird immer Ziele geben, die als sehr wichtig erachtet werden. Aber müssen es alle sein? Vermutlich nicht! Im Verlauf des Projekts können immer Situationen entstehen, in denen Entscheidungen getroffen werden müssen. Nicht selten werden davon die Ziele beeinflusst. Um diese sinnvoll priorisieren zu können, kannst du die MoSCoW-Methode anwenden.
Du willst alles über perfekte Projektziele wissen?
Für dieses wichtige Thema haben wir einen umfassenden Überblick erstellt:
✔ Die wichtigsten Grundlagen ✔ Alle Artikel auf einen Blick ✔ Videos inklusive
Was ist die MoSCoW-Methode?
Ganz einfach: Die MoSCoW-Methode ist eine einfache Möglichkeit, Anforderungen, Ziele und Aufgaben in kritische und weniger kritische Kategorien einzuteilen.
Dabei steht MoSCoW als Akronym für:
- Must (Muss)
- Should (Soll)
- Could (Kann)
- Won’t (Nicht-Ziele).
Falls du wie ich lange auf das Akronym schaust und dich wunderst, wofür die „o“ stehen: Sie haben keinerlei Bedeutung. Sie dienen nur dazu, ein hübsches Wort zu schaffen.
Wirf jetzt am besten einen Blick auf die Bestandteile im Detail:
Die Bestandteile der MoSCoW-Methode
Must
Muss-Anforderungen sind absolut entscheidend für den Projekterfolg und können nicht verhandelt werden. Werden diese Zeile nicht erfüllt, kann das Projekt nicht abgenommen werden und das Projekt gilt als gescheitert.
Beispiel:
Bei der Entwicklung eines neuen Online-Shops ist es essentiell wichtig, dass Kunden den Bestellprozess inklusive Zahlung abschließen können.
Should
Soll-Anforderungen betreffen kritische Aktivitäten mit hoher Priorität, die wann immer möglich abgeschlossen werden sollten. Sind sie nicht erfüllt, kann das Projekt nur noch mit Einschränkungen als erfolgreich abgeschlossen eingeschätzt werden.
Der wichtige Unterschied zur Muss-Kategorie: Aktivitäten können im schlimmsten Fall in ein Folgeprojekt verschoben werden. Muss-Anforderungen haben immer Vorrang.
Beispiel:
Im Online-Shop-Projekt kann der Bestellprozess komplett durchgeführt werden, jedoch sind im ersten Schritt nur Zahlungen auf Rechnung, Paypal und Kreditkarte möglich – jedoch nicht per Lastschrift.
Could
Die Erfüllung von Kann-Anforderungen wird in jedem Fall angestrebt, doch der Projekterfolg wird nicht an ihnen gemessen. Oft werden sie auch als „nice to have“ bezeichnet. Treten Zeit- oder Ressourcenkonflikte auf, können sie vernachlässigt oder verschoben werden.
Wenn sie so unwichtig sind, werden sie dann gebraucht? Durchaus! Denn oft sind sie zwar nicht elementar wichtig, machen jedoch einen großen Unterschied bei der Zufriedenheit der Stakeholder. Kann-Anforderungen sollten besonders dann näher betrachtet werden, wenn sie ohne großen Zusatzaufwand umgesetzt werden können.
Beispiel:
Der Online-Shop bietet eine Funktion, die Produkte in einer hochauflösenden 3D-Ansicht anzuschauen. Nicht elementar wichtig – aber mit großem Unterschied für den Kunden.
Would
Das „W“ in der MoSCoW-Methode wird unterschiedlich interpretiert:
- Won’t (Wird nicht umgesetzt.)
- Would (Wäre schön, aber nicht in diesem Projekt.)
- Want (Wird gewollt, aber nicht in diesem Projekt.)
Alle drei Begriffe laufen auf das gleiche hinaus: Das Projekt wird klar abgegrenzt und die Anforderungen genannt, die definitiv nicht umgesetzt werden sollen.
Warum diese Ziele überhaupt aufführen, wenn sie ohnehin nicht umgesetzt werden? Weil sie klar formulieren, was (noch) nicht angestrebt wird – was aber für den Auftraggeber wichtig für eine spätere Zusammenarbeit sein könnte.
Beispiel:
Der Online-Shop soll (zunächst) nicht in mehreren Sprachen verfügbar sein.
Wie sollten die Kategorien verteilt sein?
Gute Frage! Eine Daumenregel besagt, dass maximal 60% der Ziele in die Muss-Kategorie fallen sollten. Sind es deutlich mehr, landest du wieder beim gleichen Problem: „Wenn alles wichtig ist, ist nichts wichtig.“
Die restlichen 40% sollten sich etwa hälftig auf Soll- und Kann-Ziele aufteilen.
Diese Zahlen dienen jedoch nur als Anhaltspunkt und können je nach Projekt abweichen. Wichtig ist jedoch, sie im Hinterkopf zu behalten und hellhörig zu werden, wenn 90% der Projektziele als „Muss“ eingestuft werden – dann könnte der Projektumfang schnell ausufern bzw. es besteht kaum Spielraum wenn es zu Engpässen oder Verzögerungen kommt.
Vorteile der MoSCoW-Methode
Oft werden Projektziele nicht priorisiert. Schon diese einfache Methode bietet jedoch eine Reihe von Vorteilen:
- Für alle Beteiligten ist klar, welche Aktivitäten kritisch für den Projekterfolg sind.
- Die Erwartungshaltung von Projektteam und Stakeholdern wird abgeglichen.
- Es können leichter zu vernachlässigende Aktivitäten identifiziert werden, falls Deadlines in Gefahr sind oder Ressourcenengpässe auftreten.
- Im Gegensatz zu einer Priorisierung mit Zahlen („Was heißt noch mal 3??“) schaffen die Worte mehr Klarheit, wie wichtig eine Anforderung ist.
- Die Methode ist super-einfach umzusetzen: Ziele auflisten und mit einer der Kategorien versehen – fertig!
Fazit
Die MoSCoW-Methode ist eine sehr einfache Möglichkeit, Projektziele und Anforderungen zu priorisieren. Sie verschafft einen guten Überblick über die Prioritäten und hilft dabei, ein einheitliches Verständnis unter allen Beteiligten zu schaffen.
Hallo Andrea,
eine schöne Erklärung der MoSCoW Methode, ich hatte hierzu eine Diskussion mit einem IPMA/GPM Prüfer.
Hier wird die MoSCoW Methode nicht als Priorisierungstool anerkannt, sondern zur Kategorisierung von Zielen. Dadurch dass innerhalb der Kategorie z.b. MUST immernoch keine Priorisierung entstanden ist (und darauf kommt es m.E. an) ist keine Priorisierung geschehen, sondern lediglich eine Einordnung in Relation zum Projekterfolg.
Gruß
Hallo Benjamin,
das ist ein guter Hinweis!
Es gibt durchaus Verfechter dieser (sehr strengen) Definition von Priorisierung: Alle Elemente müssen in einer eindeutigen Priorisierungsreihenfolge vorliegen. Vergibt man also zum Beispiel Prioritäten in der Form einer durchlaufenden Nummerierung, so kann keine Priorität zweimal vergeben werden. Keine zwei Elemente können so die exakt gleiche Priorisierung erhalten.
Der Vorteil einer solchen strengen Priorisierung liegt auf der Hand: Müssen im Projektverlauf schnelle Entscheidungen zu, wechselseitigen Gunsten bzw. Ungunsten von zwei Zielen gefällt werden, so ist das mit solch einer Liste ohne viel Nachdenken möglich. So müssen idealerweise keinerlei Absprachen mit dem Lenkungskreis o.Ä. erfolgen.
Dazu allerdings zwei Anmerkungen:
1. Oben gesagter Vorteil greift meist nur den Fall, von Schwarz-Weiss-Entscheidungen (völlig Aufgabe des einen oder des anderen Zieles). Geht es hingegen nur um die Gefährdung oder Einschränkung von Zielen, ist die Situation meist zu komplex, als dass sie sich mit einer Prioritätenliste allein entscheiden liesse. Hier muss dringend eine Einzelfallbetrachtung erfolgen.
2. In der Praxis gibt es durchaus Zielepaare, denen eine identische Priorisierung gegeben werden muss. Ein Mehrwert und eine Sinnhaftigkeit entsteht erst, wenn beide Ziele erreicht werden. Ein (plakatives und nicht ganz ernst gemeintes) Beispiel:
Ziel 1: Bau eines Ausflugsrestaurants auf einer kleinen Insel im Parksee
Ziel 2: Bau einer Brücke zu besagter Insel, die das Restaurant mit den Wander- und Radwegen des Parks verbindet.
Hier künstlich eine willkürliche Unterscheidung zu erzwingen, kann später in der Praxis zu Fehlentscheidungen führen, wenn man sich zu sehr auf die Prioritätenliste verlässt.
Unter IPMA/GPM Prüfer gibt es durchaus auch sehr unterschiedliche Meinungen zu dem Thema … in einem Transfernachweis zur Zertifizierung ist es aber sicher keine schlechte Idee, auf Nummer Sicher zu gehen ;-)
Selbstverständlich ist MoSCoW das andere Extrem auf der Skala und kann nur zur groben Orientierung dienen – doch selbst die fehlt in manchen Projekten leider ;-)
Ich selbst erlebe immer wieder Projekte, in denen nach aussen vielleicht sogar eine strenge Priorisierung aufgezeigt wird um einer formalen Anforderung zu entsprechen oder „weil man es eben so macht“, intern allerdings mit maximal 3 Kategorien gearbeitet wird, da bei komplexeren Entscheidungen eh der Einzelfall betrachtet werden muss.
Viele Grüße.
Sehr schön und ein guter Ansatz um – nachdem man die Kolleginnen und Kollegen mit S.M.A.R.T. „gequält“ hat – sie auf nächste Level in Richtung Umsetzung zu bringen. Ich freu mich schon auf die Anwendung.
LG
Mark
Hallo Andrea,
ein sehr informativer Artikel zur MoSCoW-Methode, die ich bislang noch nicht kannte. Danke! Mir scheint, diese einfache und effektive Methode ist tatsächlich für jedes Projekt anwendbar. Auch für Projekte im Alltag, ja sogar im Haushalt ;-). Ich persönlich finde mich insofern darin wieder, als ich am Anfang meines Webseitenprojektes alles perfekt machen wollte und so den Online-Gang immer weiter in die Zukunft verschob – statt mich erstmal auf das Must zu konzentrieren und das Should im Blick zu behalten und: einfach anzufangen. Leider kannte ich die Methode da noch nicht.
Viele Grüße, lese immer wieder gern Ihre Artikel
Gabriele Frings
Zur Bedeutung der „o“ im Akronym:
Wenn die Abstufungsbegriffe schon in der englischen Sprache stehen, könnte man das „o“ jeweils mit dem Wort „or“ belegen und am Ende ein Fragezeichen setzen. So kommt man zu einer sinnvollen Auflösung der Abkürzung als Folge von Fragen.
Sehr gut die Beispiele zur Darstellung der Bedeutungskaskade im identischen Kontext.