Prioritäten setzen in Softwareprojekten
Priorisierung ist eine alltägliche Aufgabe in der Projektarbeit, sowohl im traditionellen als auch im agilen Projektmanagement. Gerade im agilen Projektmanagement, bzw. speziell in Scrum, spielt die Priorisierung eine bedeutende Rolle, da das Product Backlog gewichtet werden muss, damit die Product Backlog Items entsprechend ihrer Wichtigkeit umgesetzt werden können. Wenn man an agiles Projektmanagement denkt, kommt einem sofort die Softwareindustrie in den Sinn. Daher ist es nicht verwunderlich, dass Priorisierung dort eine wichtige Rolle spielt. Wie die Prioritäten in einem Softwareprojekt richtig umgesetzt werden, erfahren Sie hier.
Inhalt
Priorisieren, um Entscheidungen leichter zu treffen
Entscheidungen müssen oft schnell getroffen werden, aber das bedeutet nicht, dass alle Entscheidungen, die aus dem Bauch heraus getroffen werden, gut oder zielführend sind. Daher ist es wichtig, dass die Entscheidungsträger über alle Informationen verfügen, die sie benötigen, um eine fundierte Auswahl treffen zu können. Es ist aber nicht nur wichtig, dass alle Informationen vorhanden sind, sondern auch, dass der Entscheidungsträger eine Grundlage hat. Hier kommt die Priorisierung ins Spiel. Wenn im Vorfeld priorisiert wurde und der Entscheidungsträger sich der Priorisierung bewusst ist, kann dies in die Entscheidung einfließen, diese können schneller getroffen werden und Fehlentscheidungen werden minimiert. Auf den ersten Blick scheinen Fehlentscheidungen in diesem Szenario ein großes Übel zu sein, aber gerade bei Softwareprojekten ist es wichtig, dass Entscheidungen schnell getroffen werden, denn vor allem im Technologiesektor ist der zeitliche Vorsprung vor den Mitbewerbern der entscheidende Faktor, um einen Vorteil am Markt zu haben. Das erste Produkt seiner Art hat den First-Mover-Vorteil und damit einen klaren wirtschaftlichen Nutzen.
Die Ziele nicht aus den Augen verlieren
Um in Softwareprojekten richtig priorisieren zu können, ist es notwendig, die Ziele vor Augen zu haben. In Scrum gibt es das Product Goal, das den Developern zeigt, wohin die Reise gehen soll, so dass sie entsprechend priorisieren können. Aber auch Softwareprojekte, die nicht nach Scrum organisiert sind, haben ein Ziel, auf das hingearbeitet wird. Dies wirkt motivierend, da die Entwickler sehen, dass sie dem Ziel immer näherkommen. Zum anderen hilft es aber auch bei der Priorisierung. Denn nur wenn ein Ziel bekannt ist, können die notwendigen Schritte in die richtige Reihenfolge gebracht werden.
Schätzung und Priorisierung gehen Hand in Hand
Schätzungen spielen in Scrum eine ebenso wichtige Rolle wie die Priorisierung. Das Product Backlog wird priorisiert und die Product Backlog Items (PBI) werden geschätzt, um herauszufinden, wie viele PBIs in einem Entwicklungszyklus realisiert werden können. Die Schätzung der einzelnen PBIs erfolgt jedoch erst, nachdem die einzelnen Items in die richtige Reihenfolge gebracht wurden - die Umsetzung erfolgt erst nach der Schätzung. Die Schätzung stellt somit den Übergang von der Planungs- zur Umsetzungsphase dar. Wie üblich gilt dies nicht nur für Scrum. Auch wenn das Softwareprojekt mit einem anderen Ansatz umgesetzt werden soll, ist es sinnvoll, die einzelnen Aktivitäten abzuschätzen, damit der Kunde in Kombination mit der Priorisierung grob sehen kann, wann er mit welchem Feature rechnen kann. Beides - Schätzen und Priorisieren - ist eine sehr subjektive Tätigkeit und je öfter man es macht, desto besser wird man. Aber auch wenn schon sehr oft geschätzt oder priorisiert wurde, kann man sich manchmal gewaltig irren: Der Umfang oder der Zeitaufwand wird völlig falsch eingeschätzt oder einer Aktivität wird eine Priorität einräumt, die sie gar nicht verdient. Aber das ist menschlich. Man muss einfach dranbleiben, solche Fehleinschätzungen in künftige Schätzungen und Priorisierungen einfließen lassen und besser werden.
3 Modelle die bei der Priorisierung helfen
Wie bereits im vorigen Abschnitt erwähnt, ist die Priorisierung sehr subjektiv. Fragt man fünf verschiedene Stakeholder nach ihren Priorisierungswünschen, wird man wahrscheinlich fünf verschiedene Antworten erhalten. Natürlich möchte jeder das, was für ihn persönlich am wichtigsten ist, zuerst umgesetzt sehen und es ist nicht verwunderlich, dass die Priorisierung auseinander geht. Um aber zu vermeiden, dass nur wenige Projektbeteiligte ihren subjektiven Willen durchsetzen, ist es ratsam, die Prioritäten auf der Grundlage eines Modells zu setzen, um eine gewisse Objektivität zu erreichen. Auch eine Kombination der Modelle ist möglich und kann in vielen Projekten zu einer besseren Priorisierung beitragen, da die Problemstellungen aus unterschiedlichen Blickwinkeln betrachtet werden.
MoSCoW
Im MoSCoW-Modell wird unterschieden zwischen Anforderungen, die umgesetzt werden müssen (must), Anforderungen, die umgesetzt werden sollten (should), Anforderungen, die umgesetzt werden könnten (could) und Anforderungen, die nicht umgesetzt werden (won’t). Zuerst sollte festgelegt werden, welche Anforderungen überhaupt an das Produkt gestellt werden.
Im nächsten Schritt wird eine Liste von Kriterien erstellt, die Must-Anforderungen erfüllen müssen. Dazu gehört z. B., dass das Produkt ohne die Anforderung nicht lauffähig ist oder dass die jeweilige Anforderung gesetzlich vorgeschrieben ist.
Should-Kriterien sind Kriterien, die zusammen mit den Must-Kriterien das Produkt ausmachen, aber weggelassen oder verschoben werden können, wenn Budget oder Zeit es erfordern. Es ist jedoch zu bedenken, dass das Fehlen dieser Anforderung zu großer Unzufriedenheit bei den Stakeholdern führen kann. Dazu gehört zum Beispiel die Automatisierung bestimmter Schritte: Sie macht die Prozesse zwar effizienter, aber das Produkt kann auch ohne Automatisierung erfolgreich sein. Eine Umsetzung zu einem späteren Zeitpunkt ist ratsam.
Could-Kriterien hingegen sind "nice to have", aber nicht unbedingt notwendig für das Produkt - Anwender werden jedoch davon profitieren, so dass es wichtig sein kann, auch diese Kriterien im Auge zu behalten und umzusetzen, wenn die Zeit oder das Budget dafür vorhanden ist.
Won’t-Kriterien werden für dieses spezielle Produkt nicht umgesetzt. Da sie jedoch aus einem bestimmten Grund in den Anforderungspool aufgenommen wurden, werden sie in einen Ideenpool verschoben, damit sie nicht in Vergessenheit geraten und eventuell bei anderen Produkten berücksichtigt werden können.
Im Idealfall sollten 60 % der Produktmerkmale Must-Merkmale und jeweils 20 % Should- und Could-Merkmale sein. In der Praxis kommt es jedoch häufig vor, dass alle Anforderungen Must und Should sind. In diesem Fall ist es sinnvoll, die Priorisierung mit MoSCoW durch eine weitere Methode zu ergänzen.
Im nächsten Schritt wird eine Liste von Kriterien erstellt, die Must-Anforderungen erfüllen müssen. Dazu gehört z. B., dass das Produkt ohne die Anforderung nicht lauffähig ist oder dass die jeweilige Anforderung gesetzlich vorgeschrieben ist.
Should-Kriterien sind Kriterien, die zusammen mit den Must-Kriterien das Produkt ausmachen, aber weggelassen oder verschoben werden können, wenn Budget oder Zeit es erfordern. Es ist jedoch zu bedenken, dass das Fehlen dieser Anforderung zu großer Unzufriedenheit bei den Stakeholdern führen kann. Dazu gehört zum Beispiel die Automatisierung bestimmter Schritte: Sie macht die Prozesse zwar effizienter, aber das Produkt kann auch ohne Automatisierung erfolgreich sein. Eine Umsetzung zu einem späteren Zeitpunkt ist ratsam.
Could-Kriterien hingegen sind "nice to have", aber nicht unbedingt notwendig für das Produkt - Anwender werden jedoch davon profitieren, so dass es wichtig sein kann, auch diese Kriterien im Auge zu behalten und umzusetzen, wenn die Zeit oder das Budget dafür vorhanden ist.
Won’t-Kriterien werden für dieses spezielle Produkt nicht umgesetzt. Da sie jedoch aus einem bestimmten Grund in den Anforderungspool aufgenommen wurden, werden sie in einen Ideenpool verschoben, damit sie nicht in Vergessenheit geraten und eventuell bei anderen Produkten berücksichtigt werden können.
Im Idealfall sollten 60 % der Produktmerkmale Must-Merkmale und jeweils 20 % Should- und Could-Merkmale sein. In der Praxis kommt es jedoch häufig vor, dass alle Anforderungen Must und Should sind. In diesem Fall ist es sinnvoll, die Priorisierung mit MoSCoW durch eine weitere Methode zu ergänzen.
Opportunity Scoring
Beim Opportunity Scoring geht es darum, eine Chance (Opportunity) zu erkennen und die Priorisierung so auszurichten, dass auf dieser Basis der größte Nutzen für das Produkt erzielt wird. Dazu muss zunächst festgestellt werden, wo die Chance überhaupt liegt, d. h. welche Funktionen von den Kunden bei einem bestimmten Produkt gewünscht werden und bei welchen dieser Funktionen die Kunden unzufrieden sind und noch Verbesserungspotential sehen. Dies kann entweder dadurch geschehen, dass das Produkt bereits auf dem Markt ist und sich in der Verbesserung befindet, oder dadurch, dass man herausfindet, welches Produkt bereits existiert - z. B. von einem Konkurrenzunternehmen - aber die Kunden damit nicht zufrieden sind. Diese Lücke zwischen Kundenwunsch und Unzufriedenheit muss geschlossen werden, denn hier liegt ein großes Potenzial. Ist die Lücke identifiziert, müssen die Schritte zur Schließung der Lücke gefunden und priorisiert werden. Es muss überlegt werden, welcher Schritt am sinnvollsten zuerst unternommen wird, um die Kundenzufriedenheit zu erhöhen und davon zu profitieren.
Kano-Modell
Das Kano-Modell stellt den Zusammenhang zwischen Kundenzufriedenheit und erfüllten Qualitätsmerkmalen grafisch dar. Die Kundenzufriedenheit bewegt sich zwischen niedrig und hoch und die Qualitätsmerkmale können auf einer Skala zwischen nicht erfüllt und erfüllt dargestellt werden. Im Kano-Modell gibt es drei zentrale Merkmale:
Leistungsmerkmale werden vom Kunden aktiv nachgefragt - die Priorität ist daher mittelhoch und vergleichbar mit den Should-Kriterien des MoSCoW-Modells. Um beim Beispiel Smartphone zu bleiben: Eine gute Bildschirmauflösung ist ein Leistungsmerkmal.
Begeisterungsmerkmale sind nicht selbstverständlich und werden von Kunden nicht aktiv nachgefragt, weil sie nicht wissen, dass sie begeistert werden. Ein Beispiel wäre eine sehr lange Akkulaufzeit, ohne dass die Auflösung oder das Aussehen des Smartphones darunter leiden. Hier wird es kompliziert, denn diese Eigenschaften haben die geringste Priorität, weil sie nicht dazu beitragen, dass das Produkt überhaupt funktioniert - aber wenn ein Produkt diese Eigenschaften hat, hebt es sich deutlich von anderen Produkten seiner Art ab. An dieser Stelle muss das Team einen Weg finden, diese Eigenschaften zu integrieren, ohne sich in ihnen zu verlieren.
- die Basismerkmale,
- die Leistungsmerkmale und
- die Begeisterungsmerkmale.
Leistungsmerkmale werden vom Kunden aktiv nachgefragt - die Priorität ist daher mittelhoch und vergleichbar mit den Should-Kriterien des MoSCoW-Modells. Um beim Beispiel Smartphone zu bleiben: Eine gute Bildschirmauflösung ist ein Leistungsmerkmal.
Begeisterungsmerkmale sind nicht selbstverständlich und werden von Kunden nicht aktiv nachgefragt, weil sie nicht wissen, dass sie begeistert werden. Ein Beispiel wäre eine sehr lange Akkulaufzeit, ohne dass die Auflösung oder das Aussehen des Smartphones darunter leiden. Hier wird es kompliziert, denn diese Eigenschaften haben die geringste Priorität, weil sie nicht dazu beitragen, dass das Produkt überhaupt funktioniert - aber wenn ein Produkt diese Eigenschaften hat, hebt es sich deutlich von anderen Produkten seiner Art ab. An dieser Stelle muss das Team einen Weg finden, diese Eigenschaften zu integrieren, ohne sich in ihnen zu verlieren.
Abschließende Worte
Das Setzen von Prioritäten ist im Projektmanagement grundsätzlich wichtig und Softwareprojekte profitieren in besonderem Maße davon. Denn gerade Softwareprojekte leben davon, dass sie sich von Konkurrenzprodukten abheben und den Anwendern einen spürbaren Nutzen bieten. In diesem Bereich ist es wichtig, die richtige Funktion zur richtigen Zeit zu liefern, um einen Marktvorteil zu haben. Um dies zu erreichen werden die gewünschten Funktionen priorisiert und entsprechend umgesetzt. Um eine gemeinsame Basis zu schaffen, ist es sinnvoll, Priorisierungsmodelle zu Rate zu ziehen, damit diese möglichst objektiv erfolgen kann. So können die Wünsche in der möglichst richtigen Reihenfolge abgearbeitet werden und dazu beitragen, dass das Produkt dem Anwender einen Mehrwert bietet und letztendlich dem Unternehmen einen wirtschaftlichen Nutzen bringt.
Autor: IAPM intern
Schlagworte: Projektmanagement, Priorisierung, Agiles Projektmanagement