Home
Ressourcen
BlogBest Practices
Über unsKontakt
Demo buchenLogin
← Zum Blog

Projektportfolio priorisieren: So treffen Programm-Manager nachvollziehbare Entscheidungen

6. August 2026 · 5 Min. Lesezeit

Priorisierungs-Frameworks gibt es mittlerweile wie Sand am Meer, und trotzdem läuft es in den meisten Portfolio-Boards am Ende auf das HIPPO hinaus, the highest paid person's opinion. Das ist weniger schlimm als sein Ruf, denn Erfahrung ist durchaus ein legitimes Kriterium. Schwierig wird es erst, wenn diese Meinung schlecht informiert entscheiden muss.

Portfolio-Priorisierung scheitert selten an der Formel. Sie scheitert an der Informationslücke zwischen Fachbereich und Entscheidern.

Das eigentliche Problem ist die Informationslücke

An den Frameworks selbst liegt es meistens nicht. WSJF, Scoring-Matrix, Kosten-Nutzen-Diagramm: Die Formeln sind nicht falsch, sie lösen nur das Problem nicht, an dem Priorisierung in der Praxis scheitert. Der Fachbereich versteht die Technik und sitzt auf Daten, die die Entscheider nicht haben. Die Entscheider verstehen die Finanzkennzahlen und agieren entlang einer Strategie, die der Fachbereich wiederum nicht kennt. So schätzt die Fachabteilung eventuell falsch ein, wie ein Produkt vertrieben wird, während das Controlling nicht versteht, dass ein bestimmtes Feature die ganze Zielgruppe ändern kann. Am Ende kann keiner der beiden eine gute Einschätzung treffen, und in diese Lücke fällt jede Priorisierung, egal welches Framework auf den Folien steht.

Die Lösung ist im Grunde bekannt: Der Fachbereich, der die Lösung versteht, muss auf ein Niveau gebracht werden, auf dem er die Sprache der Entscheider spricht, also Finanzkennzahlen und Strategie. Mit Excel-Templates und Scoring-Modellen scheitert das allerdings regelmäßig in der Umsetzung, weil sie entweder unflexibel oder unverständlich sind. Bayescase, unsere Software für die Bewertung und Priorisierung von Innovations- und Kostensenkungsprogrammen, ist im Kern der Versuch, genau diese Übersetzung praktikabel zu machen: Der Fachbereich beschreibt sein Vorhaben, heraus kommt ein Business Case in der Sprache der Entscheider.

Wie ein Board nachvollziehbar priorisiert

Das Setup ist unspektakulär. Es gibt ein vorher festgelegtes Budget für die Periode, und es gibt ein, maximal zwei vorher festgelegte Kriterien, anhand derer entschieden wird, mit einer klaren Rechtfertigung, warum genau diese. Üblicherweise arbeitet man mit dem NPV.

Dann werden alle Projekte triagiert: sicheres Ja, Vielleicht, sicheres Nein. Das kann fast automatisch passieren, basierend auf dem verfügbaren Budget. Ein Teil des Budgets (z. B. 70 %, den Anteil kann man selbst wählen) wird mit den sicheren Jas gefüllt. Für den Rest nimmt man bewusst doppelt so viele Projekte ins Vielleicht, wie noch ins Budget passen, und diese Vielleichts werden alle diskutiert. Genau dort, am Cutoff, ist die Priorisierung nämlich am wichtigsten, und genau dort haben die softeren Faktoren ihren legitimen Platz: Strategie, Erfahrung, die Einschätzung der erfahrenen Leute im Raum. Je mehr Zeit man sich für diese Diskussion nehmen will, desto kleiner wählt man den Anteil der sicheren Jas.

Das Ergebnis ist immer eine priorisierte Liste. Und sie ist kein Automat mit Türsteher: Das Management kann ein strategisch wichtiges Projekt jederzeit hochziehen, auch aus den sicheren Neins, denn mit einem Business Case lässt sich nie alles abbilden. Wichtig ist lediglich, dass derjenige dabei sieht, welche Projekte er dafür depriorisiert. Und dass alle Beteiligten ihren gesunden Menschenverstand behalten.

Und die Muss-Projekte?

Für Compliance, Regulatorik und ähnliche Pflichten gibt es zwei Lesarten. Entweder man rechnet auch für sie einen Business Case, was aufschlussreicher ist, als es klingt, denn Compliance ist an einigen Stellen verhandelbarer als gedacht, und die Extremfälle (Kosten eines abgebrannten Rechenzentrums mal Eintrittswahrscheinlichkeit) schaffen es ohnehin ins Budget. Oder man lässt sie außerhalb des Portfolios laufen und reduziert das Budget um den entsprechenden Teil. Beides ist vertretbar. Wissen sollte man nur: Hin und wieder stellt sich heraus, dass ein Muss-Projekt gar nicht so must-have ist. Dann hat sich die Rechnung gelohnt.

Stoppen gehört zur Priorisierung

Der unangenehmste Teil kommt nach der Budgetrunde. Scheiternde Projekte werden fast immer zu spät gestoppt, weil Menschen an ihren Projekten hängen, und für jedes alte Projekt, das weiterläuft, wird ein neues, vielversprechendes nicht umgesetzt. Diese Portfoliohygiene ist deutlich wichtiger, als ihr Platz auf der Agenda vermuten lässt. Einfacher wird sie, wenn jedes Projekt von Anfang an ein gesetztes, P&L-relevantes Ziel hat und klare Abbruchkriterien dazu (etwa: Wahrscheinlichkeit der Zielerreichung unter 20 % heißt Reevaluation oder Stopp). Dann wird getrackt, und wenn gestoppt wird, ist für alle nachvollziehbar, warum. Das nimmt der Entscheidung das Persönliche, und genau daran scheitert das Stoppen sonst.

Häufige Fragen

Wie priorisiere ich ein Projektportfolio nachvollziehbar?
Mit einem vorab festgelegten Budget und ein bis maximal zwei vorab festgelegten Kriterien (üblicherweise dem NPV), gegen die alle Projekte triagiert werden: sicheres Ja, Vielleicht, sicheres Nein. Ein Teil des Budgets wird mit den sicheren Jas gefüllt, ins Vielleicht kommen bewusst doppelt so viele Projekte, wie noch ins Budget passen, und diese werden alle diskutiert, denn am Cutoff zählt die Priorisierung am meisten. Softe Faktoren wie Strategie und Erfahrung ändern dort die Reihenfolge. Das Ergebnis ist eine priorisierte Liste, bei der sichtbar bleibt, welches Projekt für welches andere weicht.
Wie geht man mit Muss-Projekten (Compliance, Regulatorik) im Portfolio um?
Entweder man rechnet auch für sie einen Business Case, denn manche Pflicht ist verhandelbarer als gedacht und die echten Extremfälle schaffen es ohnehin ins Budget. Oder man lässt sie außerhalb des Portfolios laufen und reduziert das verfügbare Budget entsprechend. Beides funktioniert, solange die Muss-Projekte nicht ungeprüft an der Priorisierung vorbeilaufen.
Wann sollte man ein laufendes Projekt stoppen?
Wenn ein vorab gesetztes, P&L-relevantes Ziel mit klaren Abbruchkriterien verfehlt wird, etwa sobald die Wahrscheinlichkeit der Zielerreichung unter 20 % fällt. Werden Ziel und Kriterien vor dem Start vereinbart und laufend getrackt, ist für alle nachvollziehbar, warum gestoppt wird, und die Entscheidung verliert das Persönliche, an dem das Stoppen sonst scheitert.
Lukas Mayer

Geschrieben von

Lukas Mayer

Co-Founder & COO, Bayescase

BEREIT LOSZULEGEN?

Bau deinen Business Case mit Bayescase

Modelliere Unsicherheit, rechne Szenarien und erstelle Business Cases, denen man wirklich vertraut.

Demo buchen