Projektmanagement-ABC: M wie MOSCOW

Effiziente Priorisierung von Projektzielen mit der MOSCOW-Methode

Was ist die MOSCOW-Methode?

Die MoSCoW-Methode wurde in den 1990er Jahren von Dai Clegg, einem Berater bei Oracle, entwickelt. Sie entstand im Kontext der Rapid Application Development (RAD) Methodologie und sollte die Identifikation und Priorisierung von Anforderungen in schnellen Entwicklungszyklen unterstützen. Seit ihrer Einführung hat sich die MoSCoW-Methode in verschiedenen Branchen etabliert und wird häufig in agilen Projektmanagement-Frameworks wie SCRUM und DSDM (Dynamic Systems Development Method) eingesetzt, wo sie Projektleitende dabei unterstützt, den Fokus auf die wichtigsten Aufgaben oder Ziele zu richten und eine klare Priorisierung zu gewährleisten. Dies führt zu einer effektiveren Nutzung von Zeit und Ressourcen, da die wesentlichen Anforderungen zuerst angegangen werden. Zudem erleichtert die Methode die Kommunikation mit Stakeholdern, da klar ersichtlich ist, welche Anforderungen kritisch sind und welche verschoben werden können. Dies fördert eine realistische Erwartungshaltung und eine bessere Planung.
Der Name „MoSCoW“ ist ein Akronym, das die vier Hauptkategorien von Anforderungen beschreibt: Must-Have (M), Should-Have (S), Could-Have (C), und Won’t-Have (W) – die Os dienen nur dazu, ein schöneres Akronym zu schaffen und haben keine Bedeutung.

Die Kategorien der MoSCoW-Methode

Must (M)

Muss-Anforderungen sind unverzichtbar und müssen erfüllt werden, damit das Projekt erfolgreich ist. Sie sind nicht verhandelbar, da ohne Erfüllung dieser Punkte das Projekt als gescheitert gilt.

Beispiele:

• Kernfunktionen eines Produktes, ohne die der Hauptzweck nicht erfüllt wird.
• Sicherheitsfunktionen, die notwendig sind, um gesetzliche Vorschriften einzuhalten.
• Mindestanforderungen an die Leistung oder Verfügbarkeit eines Systems.

Should (S)

Soll-Anforderungen sind ebenfalls wichtig und sollten nach Möglichkeit umgesetzt werden. Ihr Fehlen beeinträchtigt die Qualität oder den Nutzen des Projektergebnisses. Dennoch kann das Projekt mit Einschränkungen als erfolgreich abgeschlossen gelten, wenn sie nicht erfüllt werden. Die Priorität der Soll-Anforderungen liegt gleich nach den Muss-Anforderungen. Das bedeutet, dass diese Anforderungen im schlimmsten Fall in ein Folgeprojekt verschoben werden können, wenn sämtliche Zeit und Ressourcen benötigt werden, um die Muss-Anforderungen zu erfüllen.

Beispiele:

• Zusätzliche Funktionen eines Produktes, die den Wettbewerbsvorteil erhöhen, aber nicht kritisch sind.
• Erweiterte Benutzerschnittstellen einer Software, die die Nutzererfahrung verbessern.
• Verbesserungen in der Effizienz, die jedoch nicht absolut notwendig sind.

Could (C)

Kann-Anforderungen sind wünschenswert, weil sie beispielsweise einen höheren Nutzen des Projektes oder mehr Komfort bieten. Die Erfüllung dieser Anforderungen wird angestrebt, sie sind jedoch nicht kritisch für den Projekterfolg und werden daher nur umgesetzt, wenn nach der Erfüllung der Must-Have- und Should-Have-Anforderungen noch Zeit und Ressourcen zur Verfügung stehen. Treten Ressourcenkonflikte auf, werden die Kann-Anforderungen nicht umgesetzt oder in ein Folgeprojekt verschoben.
Diese Anforderungen machen häufig einen grossen Unterschied bei der Zufriedenheit der Stakeholder. Daher ist es wichtig, sie im Blick zu behalten und aufzulisten. So können sie näher betrachtet werden, wenn sie ohne grossen Zusatzaufwand umgesetzt werden können.

Beispiele:

• Zusätzliche Optionen oder Einstellungen, die allerdings nur selten genutzt werden.
• Kosmetische Verbesserungen der Benutzeroberfläche einer Software.
• Verbesserungen einer Software, die die Wartung erleichtern oder die Skalierbarkeit erhöhen, aber aktuell nicht erforderlich sind.

Won’t (W)

Das W in der Methode kann unterschiedlich interpretiert werden:

• Won’t betrifft Anforderungen, die nicht umgesetzt werden.
• Would sind Anforderungen, die schön wären, aber nicht in diesem Projekt umgesetzt werden können.
• Want sind Anforderungen, die gewollt werden, trotzdem aber nicht im Rahmen dieses Projektes umgesetzt werden, sondern in Folgeprojekten.

All diese Interpretationen haben gemeinsam, dass diese Anforderungen in dem aktuellen Projektzyklus definitiv nicht umgesetzt werden. Sie werden aber aufgeführt, um Missverständnisse zu vermeiden und um sie bewusst zurückzustellen oder für zukünftige Projekte in Betracht zu ziehen. So hilft diese Kategorie, den Projektumfang zu kontrollieren und Anforderungen im Blick zu behalten, die für eine spätere Zusammenarbeit mit dem Auftraggeber wichtig sein könnten.

Beispiele:

• Funktionen, die zwar interessant, aber momentan nicht relevant sind.
• Anforderungen, die erst in späteren Versionen des Produktes von Bedeutung sein könnten.
• Verbesserungen, die aufgrund von Ressourcenbeschränkungen oder Zeitmangel nicht umgesetzt werden können.

Wie sollten die Kategorien verteilt sein?

Die Verteilung der Kategorien in einem Projekt sollte ausgewogen und realistisch sein, um sicherzustellen, dass das Projekt erfolgreich abgeschlossen wird, ohne das Team zu überfordern oder wichtige Aspekte zu vernachlässigen. Achtet man nicht auf die Verteilung kann es nämlich passieren, dass alle Anforderungen in der Kategorie «Must» landen und dann wiederum keine Priorisierung vorgenommen werden kann. Eine Daumenregel besagt daher, dass maximal 60 bis 70 Prozent aller Anforderungen absolut kritisch sein dürfen und daher in die Muss-Anforderungen kategorisiert werden können. Dies stellt sicher, dass der Fokus wirklich auf den essenziellen Anforderungen an das Projekt liegt. 20 bis 25 Prozent der Anforderungen sind wichtig und tragen wesentlich zur Qualität und zum Nutzen des Projektes bei und werden daher der Kategorie «Should» zugeordnet. Weitere 5 bis 10 Prozent der Anforderungen können in die Kategorie «Could» fallen, während nur 0 bis 5 Prozent in die letzte Kategorie eingeordnet werden sollten.

Vorteile der MoSCoW-Methode

• Klare Priorisierung: Durch den starken Fokus zunächst auf Must-Have und dann auf Should-Have Anforderungen, wird sichergestellt, dass die Projektziele erreicht werden. Gleichzeitig wird das Projektteam so nicht von weniger wichtigen Anforderungen abgelenkt.
• Effiziente Ressourcennutzung: Da die wichtigsten Anforderungen zuerst bearbeitet werden, wird gewährleistet, dass die wesentlichen Projektziele mit den verfügbaren Ressourcen auf jeden Fall erreicht werden erreicht werden. Gleichzeitig ermöglicht die Methode es, weniger wichtige Anforderungen (Could-Have) zu berücksichtigen, wenn zusätzliche Ressourcen vorhanden sind.
• Verbesserte Kommunikation: Die klare Kategorisierung erleichtert die Kommunikation mit Stakeholdern und Teammitgliedern über Prioritäten und Projektziele und hilft so bei transparenten Entscheidungen. Gleichzeitig sorgt die Kategorisierung dafür, dass Stakeholder besser verstehen, was sie erwarten können, welche Anforderungen realistisch umsetzbar sind, und welche zurückgestellt werden.
• Flexibilität und Anpassungsfähigkeit: Die Methode ist flexibel und kann an sich ändernde Anforderungen und Rahmenbedingungen angepasst werden, was besonders in agilen Projekten von Vorteil ist. So ermöglicht sie eine iterative Annäherung an Projektziele, wobei die Prioritäten kontinuierlich überprüft und angepasst werden können.

Herausforderungen und Nachteile der MoSCoW-Methode

Trotz ihrer vielen Vorteile gibt es auch einige Herausforderungen und potenzielle Nachteile, die bei der Anwendung der MoSCoW-Methode berücksichtigt werden sollten:

• Subjektivität bei der Priorisierung: Unterschiedliche Stakeholder können unterschiedliche Ansichten darüber haben, welche Anforderungen Must-Have oder Should-Have sind, was zu Konflikten führen kann. Es kann zeitaufwendig sein, einen Konsens über die Priorisierung zu erzielen, insbesondere in grossen oder heterogenen Teams.
• Überladung der Must-Have-Kategorie: Es besteht die Gefahr, dass zu viele Anforderungen als Must-Have eingestuft werden, was die Priorisierung weniger effektiv macht. Gleichzeitig kann eine übermässige Anzahl von Must-Have-Anforderungen das Team überfordern und den Projekterfolg gefährden.
• Fehlende Berücksichtigung von Abhängigkeiten: Die Methode berücksichtigt nicht automatisch Abhängigkeiten zwischen Anforderungen, was insbesondere in komplexen Projekten zu Planungsproblemen führen kann.
• Statische Priorisierung: Insbesondere in agilen Projekten können Prioritäten sich ändern und müssen an neue Erkenntnisse angepasst werden. In solchen Fällen sollte die Prioritätenliste nicht starr sein, sondern regelmässig überprüft werden, auch wenn dies zusätzlichen Aufwand bedeutet.

Fazit

Die MoSCoW-Methode bietet eine strukturierte und effektive Möglichkeit, Anforderungen im Projektmanagement zu priorisieren. Durch die klare Kategorisierung kann ein Projektteam sicherstellen, dass die wichtigsten Ziele zuerst erreicht werden, ohne dabei Ressourcen zu verschwenden oder den Fokus zu verlieren. Trotz einiger Herausforderungen, wie der möglichen Subjektivität bei der Priorisierung und der Notwendigkeit regelmässiger Anpassungen, ermöglicht die MoSCoW-Methode eine transparente und flexible Projektplanung, die sowohl die Effizienz als auch die Kommunikation innerhalb des Teams und mit den Stakeholdern verbessert. 

Erfahren Sie mehr über die Projekt- und Portfoliomanagementsoftware myPARM:

Sie möchten myPARM in einer Demovorführung kennenlernen? Dann vereinbaren Sie gleich einen Termin mit uns!