Direkt zum Hauptbereich

Ein kurzer Business Case

Projekte brauchen eine (fortlaufende) wirtschaftliche Rechtfertigung. Es ist eine gute Idee, sog. Business-Cases zu erstellen. In der Praxis gibt es allerdings Probleme: entweder wird überhaupt kein Business-Case erstellt oder das Dokument wird so umfangreich, dass es keiner prüft. Dann haben wir noch das Problem, dass sie oft nicht stimmen. In diesem Beitrag schlage ich eine Kurzform auf einer Seite vor, um die nächsten Schritte zu starten.

Wozu dient ein Business-Case?

Business Cases haben für mich einen ganz praktischen Zweck: sie sollen verhindern, dass eine Organisation zu viele Projekte gleichzeitig startet. Viele Projekte werden mit großem Elan gestartet und verhungern über die Zeit, weil andere Projekt irgendwie auch wichtig sind. Dieses Vorgehen verzögert die Lieferung von Wert signifikant und frustriert alle Beteiligten. Wenn ein Projekt einen großen Nutzen erzeugt, sollte es schnellstmöglich (erfolgreich) abgeschlossen werden.

Der Wert von Business Cases liegt also nicht in dem einzelnen Dokument, sondern in allen Cases für Projekte, die als Nächstes geplant sind. Wenn wir wissen, dass wir uns immer zu viel vornehmen, können wir mithilfe der Business Cases entscheiden, worauf wir uns fokussieren. Dazu wäre es praktisch, die wichtigsten Informationen auf einer Seite darzustellen.

Was brauchen wir in einem Business Case?

Wir sind in einer frühen Phase. Wir sollten nicht zu viel Zeit in die Vorbereitung eines Business Case stecken, wenn wir nicht sicher sind, ob wir das Projekt machen. In dieser Situation herrscht noch große Unsicherheit:

  • Wir wissen zu wenige Details über die Lösung.
  • Daher können wir weder die Kosten noch den Nutzen konkret berechnen.

Aber wir wissen schon andere Punkte:

  • Wir wissen, warum wir das Projekt brauchen.
  • Wir wissen, welche Geschäftsprozesse davon betroffen sind.
  • Wir können Größenordnungen über Kosten und Nutzen abschätzen.

Diese Informationen bereiten wir auf einer Seite auf. Mit etwas Vorbereitung kann das im Team in wenigen Stunden abgeschlossen werden.

Ein erster Business-Case könnte durch folgende Informationen beschrieben werden:

  • Titel: Wie nennen wir das Projekt?
  • Ziele: Was wollen wir eigentlich erreichen? Es ist niemals das Ziel, eine bestimmte technische Lösung zu bauen. Projekte bauen Fähigkeiten auf. Wie können wir diese beschreiben? Welche Leistungsanforderungen gelten dafür?
  • Optionen: Auch wenn wir eine präferierte Lösung haben, sollten wir trotzdem mehrere Optionen aufführen. Mit welchen anderen einfachen und aufwendigen Lösungen können wir die Ziele auch erreichen? Es besteht sonst die Gefahr, dass wir auf die falsche Lösung setzen und keine Alternativen sehen.
  • Nutzen: Bevor wir auf die Kosten gehen, sollten wir auf den Nutzen eingehen. Nutzen könnten zusätzliche Einnahmen, eingesparte Kosten oder eine deutlich verbesserte Qualität sein. Den Nutzen bekommen wir nur, wenn wir dauerhaft unsere geschäftlichen Abläufe ändern. Welche Änderungen bringen uns den Nutzen? Wir brauchen übrigens keine perfekten und diskreten Zahlen. Oft reichen schon Bandbreiten.
  • Kosten: Wo entstehen einmalig oder dauerhaft Kosten, die wir gegenfinanzieren müssen? In welcher Größenordnung?
  • Investitionsstrategie: Bei hoher Unsicherheit ist vernünftig, nicht gleich alles Geld auf einmal auszugeben. Wir können uns einzelne Schritte überlegen, durch die wir uns Wissen kaufen. Zum Beispiel können wir statt direkt 2 Mio. EUR auszugeben, das Projekt in Phasen einteilen: Was können wir mit 10.000 EUR anfangen, um eine erste Lösung zu bauen, um zu sehen, ob die Lösung etwas bringt? Im nächsten Schritt könnten wir 100.000 EUR investieren und danach 200.000 EUR. Wenn der erste Schritt zeigt, dass es keine gute Lösung gibt, haben wir nur 10.000 EUR verloren (statt 2 Mio.). Nach dem zweiten Schritt hätten wir nur 110.000 EUR verloren usw. Was sind also sinnvolle Zwischenschritte, um zu lernen?
  • Rückzahlungsstrategie: Projekte werden nicht genehmigt, sondern finanziert. Wer Geld gibt, erwartet irgendwann einen Nutzen. In welchen Schritten liefern wir den Nutzen? Nutzen kann Geld (mehr Umsatz oder weniger Kosten) sein. Es können auch Features sein, auf die andere schon lange warten. Wann kommt frühestens das Geld? Wann bekommt der nächste etwas?

Diese Informationen können wir auf einer DIN-A3-Seite oder auf einem Flipchartblatt sammeln.

Vorlage für einen Business Case auf einer Seite

Was sind die Vorteile dieses Formats?

Wenn wir über die nächsten Projekte entscheiden, können wir alle Ideen besser vergleichen. Wir haben mit dieser Vorlage folgende Erfahrungen gemacht:

  • Es wird überhaupt so etwas wie ein Dokument zur wirtschaftlichen Rechtfertigung erstellt.
  • Es geht schneller, als alle Beteiligten erwartet hatten.
  • Wenn man sich selbst zwingt, über mehrere Lösungswege nachzudenken, fallen einem noch bessere Lösungen ein. Durch geschicktes Nachfragen bekommt man schnell heraus, worum es eigentlich geht.
  • Wenn man vorab über eine Investitions- und eine Rückzahlungsstrategie nachdenkt, kann man das Projekt besser planen. Wir können die technische Umsetzung so planen, dass man schon früher etwas sieht oder zeigen kann.
  • Wenn wir behutsam investieren, kann man Abbruchbedingungen oder Lernziele definieren. Schlechte Projekte sollten frühzeitig gestoppt werden.
  • Früher haben Führungskräfte die Fehler in den Business-Cases gesucht. Mit diesem Format führen sie ihre Mitarbeiter:innen und kommen durch gute Fragen auf neue Ideen.

Ersetzt diese Vorlage klassische Business-Cases? Wahrscheinlich nicht. Sie sind eine gute Quelle für die nächste Version des Business Cases. Sie regen zum Lernen an und helfen den Beteiligten beim Formulieren der nächsten Fragen.

Wer tiefer in das Thema Business Cases eintauchen will, findet in diesen Büchern gute Anregungen:

 

Sie wollen mehr über gute Projektarbeit lernen? Es gibt eine Übersichtsseite zum Thema Projektmanagement in diesem Blog. Dort finden Sie weitere Artikel, mit denen Sie sich in das Thema einlesen können.

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Der Softwareeisberg, die Softwarepyramide - Wie sprechen wir über neue Software?

Software ist aus den Geschäftsprozessen vieler Unternehmen nicht mehr wegzudenken. Sie verwaltet Kunden- und Produktdaten. Sie automatisiert Abläufe und verhindert Fehler. Aber Software veraltet. Was machen wir, wenn wir Unternehmenssoftware erneuern müssen? Von den ersten Konzepten bis zum ersten Release ist es ein weiter Weg, mit vielen Entscheidungen. Wie sprechen wir über diese Entscheidungen?