Priorisieren in der täglichen Projektarbeit: Fokus auf echte Geschäftswerte

In komplexen Projekten mit entsprechendem Kostenrahmen ist es für alle Beteiligten wichtig, stets die Elemente im Scope zu haben, die für die Auftraggeber den höchsten Geschäftswert besitzen. Aufgaben also, die direkt Umsätze mit den Endbenutzern ermöglichen und so dazu beitragen, das Budget optimal einzusetzen – und zu rechtfertigen. Doch das gelingt vielen Unternehmen und auch manchen ihrer Dienstleister nicht in jedem Fall. In der täglichen Arbeit stehen vielmehr regelmäßig Elemente nur deshalb im Vordergrund, weil sie bereits im Detail spezifiziert und für die Umsetzung aufbereitet sind – unabhängig von ihrem tatsächlichen geschäftlichen Wert. Viele “wertvolle User Stories” mit klarem ROI für den Auftraggeber bekommen dadurch nicht die angemessene Priorität oder bleiben gar längere Zeit unbearbeitet liegen. Das resultiert in Projektfortschritten, die einen geringeren Geschäftswert abbilden als möglich gewesen wäre.

In diesem Artikel zeigen wir Ihnen, was die Ursachen dafür sind und wie Projektteams auch in komplexen Projekten den richtigen Fokus beibehalten können.

→ SAFe: Digitale Transformation mit Tempo und Skalierung

Warum ist das so?

Grundlegende Anforderungen werden zu Projektbeginn auf einer hohen Abstraktionsebene definiert – aber danach passiert oft eine lange Zeit nichts mehr. So erhalten die Beteiligten zwar die (wichtige) übergeordnete Sicht auf die “Vision”, doch deren Umsetzung in konkret priorisierte Arbeitspakete wandert ins Tagesgeschäft ab.

Manche Anforderungen ändern sich zudem im Projektverlauf, woraus neue Priorisierungen abgeleitet werden müssen. Das erschwert es, ein gemeinsames Verständnis bei allen Beteiligten für die geltenden Anforderungen an ein Projekt zu wahren.

Auch der Detailgrad der Beschreibung einer konkreten Anforderung hat einen Einfluss: Je näher der Umsetzungszeitpunkt rückt, desto detaillierter und klarer muss die Beschreibung sein, um eine realistische Chance auf priorisierte Umsetzung zu haben.

Und nicht zuletzt kann es durchaus unterschiedliche subjektive Einschätzungen darüber geben, wann eine Anforderung angemessen beschrieben ist.

Die vollständige Beschreibung aller aktuellen Anforderungen und die fortlaufende Pflege eines gemeinsamen Verständnisses der relevanten Geschäftswerte können also die richtige Priorisierung einzelner Arbeitspakete in der täglichen Projektarbeit deutlich erleichtern. Dafür bedarf es der Unterstützung sämtlicher Stakeholder des Projekts, und ein gehöriges Maß an Transparenz.

Probleme bei der Priorisierung

In der Regel gelingt dies nicht auf Anhieb, sondern ist ein längerer Prozess. Bei dem Versuch stößt man oft auf eines oder beide der folgenden Probleme:

• Die Auftraggeber eines Projekts fordern langfristige fachliche Commitments ein, bestehen auf fixen Releaseplänen und kontrollieren deren Einhaltung penibel, ohne flexibel auf Veränderungen bei den Anforderungen zu reagieren.
• Die Beteiligten werden darauf eingeschworen, einen langfristigen Plan zum Erfolg zu bringen und dafür im Zweifel die Planungssicherheit über den Geschäftswert des Projekts zu stellen.

Diese Probleme können die korrekte Priorisierung einzelner Elemente und die detaillierte Bewertung der zugehörigen Stories erschweren und sollten deshalb vorher geklärt werden. Denn etwas Unspezifiziertes anzugehen führt oft zu doppelter Entwicklungsarbeit, weil die die ersten Ergebnisse die Erwartungen verfehlen. Das fördert weder die Einhaltung eines Releaseplans noch das Vertrauen der Auftraggeber.

Richtig Priorisieren

Gelingt es, mit allen Beteiligten gemeinsame und stets aktuelle Empfehlungen für die Priorisierung zu erarbeiten, kann das über die gesamte Projektlaufzeit dazu beitragen, kostbare Entwicklungszeit immer zuerst für die wichtigen Elemente zu verwenden, also die mit dem höchsten Geschäftswert.

Wird einem Element anhand der Empfehlungen ein hoher Geschäftswert zugerechnet, werden auch die zugehörigen User Stories priorisiert bearbeitet. Das gilt sogar dann, wenn eine Story noch nicht ausreichend detailliert beschrieben ist – denn oft deckt erst eine Annäherung an die Implementation versteckte Hindernisse für den Abschluss der Story auf. So kann ein frühes Entwicklungsstadium zur Grundlage für eine wichtige Diskussion über die Anforderungen werden.

Unterschiedliche Rollen = Unterschiedliche Prioritäten?

Doch wer sind diese “Beteiligten”, die sich alle einig werden müssen? Die Priorisierung spielt sich ab in einem Spannungsfeld unterschiedlicher Rollen und teils konkurrierender Ziele:

• Business Owner, verantwortet die Ressourcen Geld und Zeit
• Fachabteilungen, verantworten die Fachlichkeit
• Entwicklungsteams, verantworten die Umsetzung und Implementation
• Product Owner, verantworten die Arbeit des Entwicklungsteams und die Maximierung des Geschäftswertes

Im Projekt sind dabei die Product Owner von zentraler Bedeutung: Sie diskutieren die Anforderungen mit dem Entwicklungsteam bis es zu einer gemeinsamen Auffassung über die Umsetzung und den zu erwartenden Aufwand kommt. Ist das nicht möglich, müssen die Anforderungen weiter verfeinert werden.

Um den übrigen Stakeholdern die dafür relevanten Fragen stellen und noch unbekannte Hindernisse entdecken zu können, sind sogenannte “Spikes” ein sinnvolles Vorgehen. Ein Spike wird notwendig, wenn das Team nicht genug Informationen oder Erfahrung hat, um eine realistische Schätzung einer Anforderung vorzunehmen.

Projektrisiken Reduzieren mit Spikes

Ein Spike ist ein begrenzter Auftrag zur Analyse eines konkreten Problems bzw. zur Sammlung bestimmter Informationen. Ziel ist es, Unsicherheiten und damit Projektrisiken zu reduzieren. Spikes stellen und beantworten Fragen, um zu einem Ergebnis zu kommen:

• Warum? Es soll etwas umgesetzt werden, aber es ist unklar, was.
• Wozu? Verständnis aufbauen, Unklarheiten identifizieren, Unbekannte aufdecken.
• Wie? Zeitlich begrenzt, in einem definierten Zeitfenster.
• Ergebnis: Zuverlässige Einschätzung sowie ein besseres Verständnis für die Anforderung.

Es gibt unterschiedliche Verwendungen von Spikes:

• Der technische Spike wird verwendet, um verschiedene Ansätze für eine Lösung innerhalb eines Projektes zu erforschen: Das Treffen einer Build-versus-Buy-Entscheidung, die Bewertung der potenzielle Leistung oder Lastauswirkung einer neuen User Story oder die Evaluation bestimmter Implementierungstechnologien.
• Der funktionale Spike wird eingesetzt, wenn eine erhebliche Unsicherheit darüber besteht, wie ein Benutzer mit einem System interagieren könnte. Funktionale Spikes lassen sich oft durch Prototyping evaluieren – unabhängig davon, ob es sich um Benutzeroberflächen-Mockups, Wireframes, Pageflows oder andere Techniken handelt, die am besten geeignet sind, um Feedback anderer Stakeholder zu erhalten.

→ Wie Sie den richtigen Salesforce Partner für Ihr Unternehmen finden

Implikationen für die Beteiligten

Soll dieses Vorgehen mit Spikes konsequent umgesetzt werden, müssen sich alle am Projekt Beteiligten über die Implikationen für ihren Aufgabenbereich im Klaren sein.

Business Owner:

• Verantwortlich für Ressourcen und den daraus generierten Wert
• Entscheiden über Entwicklungen und Zukunftspläne
• Benötigen für fundierte Entscheidungen in kurzen Zyklen Feedback aus dem Projekt
• Rechtfertigen den Projektstatus gegenüber den Shareholdern
• Laufen Gefahr, schnell sichtbare Zwischenergebnisse zu priorisieren, um Fortschritt berichten zu können
• Müssen Vertrauen ins Team haben, ohne die gesamte Tragweite jeder Entscheidung sicher absehen zu können
• Müssen Rückschläge und geänderte Anforderungen im Projektverlauf akzeptieren und eine positive Fehlerkultur ins Team tragen

Fachabteilungen:

• Unterstützen die Definition des gemeinsamen Verständnisses der fachlichen Inhalte und ihrer Korrektheit
• Kapazitäten sind oft auf lange Sicht verplant, weshalb verfügbare Ressourcen gleich zu Projektbeginn erschöpft werden
• Treffen Entscheidungen über Detailfragen, hemmen damit aber ggf. die Flexibilität des Entwicklungsteams bei der Lösungsfindung
• Verfolgen eigene Abteilungsziele, die nicht immer mit dem Projektfokus übereinstimmen
• Wollen sich dennoch tief an Projekten beteiligen und mit fachlichem Input Probleme lösen.

Product Owner:

• Betreuen die Auftraggeber, berichten den Status und stellen sicher, dass sie sich über Planänderungen in Folge unspezifischer Anforderungen bewusst sind
• Sind häufig mit sehr vielen Stakeholdern konfrontiert, die eigene Vorstellungen einbringen in dem Bedürfnis, das Projekt voranzutreiben
• Sind der “Single Point of Truth” gegenüber allen Projektbeteiligten
• Müssen final die Prioritäten setzen und die Entwicklung auf das fokussieren, was Geschäftswerte schafft
• Sind von allen Beteiligten am besten in der Lage, frühzeitig und kontinuierlich einen echten Nutzen zu liefern

Entwicklungsteams:

• Arbeiten und entscheiden selbständig, übernehmen Verantwortung für ihre Entscheidungen
• Müssen häufig umpriorisieren, wenn die Anforderungen sich ändern
• Warnen vor Hindernissen bei der Umsetzung und empfehlen Alternativen, die zum Scope passen
• Liefern den Output, der für einen durch die Stakeholder erkennbaren Projektfortschritt benötigt wird

Sind sich alle Beteiligten über diese Implikationen für ihren Arbeitsbereich im Klaren, ist der Scope einfacher beizubehalten, und “wertvolle User Stories” erhalten eine angemessene Priorität.

So können Sie gemeinsam mit Ihren Teams und Dienstleistern regelmäßig Projektfortschritte erzielen, die klar sichtbare Geschäftswerte für alle relevanten Stakeholder abbilden. Davon profitieren nicht nur die Business Owner, sondern alle Rollen im Projekt.

Whitepaper zum Qualitätsmanagement in der Softwareentwicklung

Ihr digitales Produkt weist Fehler auf, die meist zufällig entdeckt werden? Die Behebung dauert ewig? Und neue Funktionen verursachen neue Probleme am bestehenden Produkt? Dann wird es höchste Zeit für Ihr Unternehmen, ein „Quality Mindset“ zu etablieren!