Als unabhängige Management-Beratung haben wir uns auf die Themenfelder digitale Innovation & Strategie spezialisiert. Gemeinsam mit unserem Netzwerk an Experten beraten wir branchenübergreifend Unternehmen verschiedenster Größen.

Hier stellen wir eine Auswahl der von uns verwendeten Methoden vor.

DISCUS Modell

DISCUS Methode

Lean Startup

Lean Startup

Design Thinking

Design Thinking

Business Model Canvas

Business Model Canvas

Scrum

Scrum

OKR

OKR

DISCUS Methode

Zielsetzung & Anwendung

Jedes Unternehmen hat eine eigene Identität und ist geprägt von seiner Historie, Kultur, Werten und vielem mehr. Mit unserem offenen Beratungs-Framework „DISCUS“ können wir individuell auf jeden Kunden eingehen und dennoch einen konsistenten und zielführenden Strategieprozess sicherstellen.

Das DISCUS-Modell wird je nach Situation vollständig oder in Teilen angewendet. Es verwendet Methoden der „Lean Startup“ und „Design Thinking“ Philosophie und kombiniert dieses mit Elementen der klassischen Strategieberatung.

1. Schritt: Definition of objectives

Zunächst wird das Projekt vorbereitet, indem es vor dem Hintergrund der bisherigen Ausrichtung eingeordnet wird.

  • Gesamtstrategie inkl. Purpose reflektieren
  • Beitrag und Passfähigkeit des Projektes zur Gesamtstrategie validieren
  • Ausgangslage und Problemstellung verstehen
  • Anforderungen an eine gute Lösung verstehen
  • Vorgehensweise und Liefergegenstände definieren
  • Projekt aufsetzen
  • Kick-off planen und durchführen

2. Schritt: Inspiration from in- and outside

Durch eine klar strukturierte Analysephase wird eine solide Faktenbasis geschaffen, die durch Inspiration von außen ergänzt wird.

  • (Potentielle) Kunden identifizieren, beobachten, befragen
  • Lösungsansätze aus anderen Branchen sichten
  • Technologien scouten
  • Experten interviewen
  • Marktdaten recherchieren
  • Wettbewerb analysieren

3. Schritt: Solution design

Mit Keativ-Techniken entstehen erste Ideen, die gemeinsam eingeordnet und optimiert werden.

  • Ideen entwickeln & sammeln – Brainstorming etc.
  • Ideen visualisieren – Wireframes, Post-its, Skizzen
  • Ideen vergleichen & clustern
  • Ideen priorisieren & selektieren
  • Beste Idee(n) auswählen

4. Schritt: Creation of prototypes

Um möglichst schnelles Kundenfeedback zu ermöglichen, entsteht ein einfacher Prototyp.

  • Detaillierte Ausarbeitung der gewählten Idee(n)
  • Definition MVP Leistungsumfang
  • Definition Kernhypothesen & Testkonzept
  • Entwicklung Prototyp: Klickdummy o.ä.

5. Schritt: User test & feedback

Die Interaktion mit Kunden zeigt, ob die Ideen erfolgversprechend sind – so wird klar, in welche Richtung sich das Projekt entwickeln muss.

  • Prototypen mit Usern testen (z.B. Wizard of Oz / Smoke / Usability)
  • Feedback einholen
  • Feedback und Tests auswerten
  • Abhängig vom Ergebnis: 4. Schritt (Creation) wiederholen oder Prozess fortsetzen mit 6. Schritt (Strategy)
  • Customer Journeys definieren

6. Schritt: Strategy implications

Im letzten Schritt wird auf Basis der bisherigen Ergebnisse eine Entscheidung zum weiteren Vorgehen getroffen: Pivot or Perserve. Dabei wird die Lösung auch im Hinblick auf die Umsetzbarkeit innerhalb der Organisation und die Wirtschaftlichkeit geprüft.

  • Customer Validation & Analysis abschließen (Desirability)
  • Capabilities Mapping durchführen (Feasibility)
  • Business Case berechnen (Viability)

In diesem Schritt werden die Projektergebnisse außerdem mit der Gesamtstrategie abgeglichen – denn nur mit einer solchen Rückkopplung entsteht eine kohärente Ausrichtung des Unternehmens.

  • Strategic Fit: Implikationen mit Gesamtstrategie abgleichen
  • Handlungsempfehlung ableiten
  • Dokumentation bereitstellen

Lean Startup

Build, Measure, Learn

Der Lean Startup Ansatz verfolgt einen ebenso einfachen wie wirkungsvollen Ansatz. Durch ein frühes Kundenfeedback soll eine Verschwendung von Ressourcen in der Entwicklung neuer Services und Produkte bestmöglich vermieden werden. Die Methodik ist in enger Anlehnung an die Arbeit von Taiichi Ohno, der das Lean Manufacturing des Toyota Production System (TPS / 1948-1975) maßgeblich entwickelt hat, entstanden.

Eric Ries hat diese Philosophie auf die Startup Welt übertragen und mit seinem Bestseller „The Lean Startup“ (2011) populär gemacht. Er selbst schreibt zu seinem Ansatz:

The Lean Startup asks people to start measuring their productivity differently. Because startups often accidentally build something nobody wants, it doesn’t matter much if they do it on time and on budget. The goal of a startup is to figure out the right thing to build – the thing customers want and will pay for – as quickly as possible. (Ries, 2011).

Wir adaptieren diese Philosophie in unserer Beratung und suchen frühstmöglich das oft schonungslose Feedback des Marktes. Dies erfordert eine klare Fokussierung auf jene Tätigkeiten, die uns dabei unterstützen, eine bloße Idee in klare und belastbare Fakten zu überführen. Eric Ries schreibt hierzu:

Most startups lack a structures process for testing their business models’ hypotheses – markets, customers, channels, pricing – and for turning those guesses into facts. The traditional new product introduction model offers no customer feedback until beta, when it‘s too late. (…) Validated learning means nothing less than that “effort that is not absolutely necessary for learning what customers want should be eliminated“ (Ries, 2011).

Während Ries seine Ausführungen primär auf Startups bezieht, verwenden wir große Teile seiner Philosophie in der Verprobung neuer Konzepte und Ideen – auch in großen Unternehmen.

Das Konzept des frühen und konstanten Kundenfeedbacks ist in einem dreistufigen Kreislauf (Build, Measure, Learn) verankert. Neue Ideen werden so lange getestet und überarbeitet, bis ein positives Feedback vorliegt (Beginn der Umsetzung) oder die Idee als nicht zielführend eingestellt wird. Größere Anpassungen innerhalb dieses Kreislaufes werden als „Pivot“ bezeichnet.

Design Thinking

Innovation aus Anwenderperspektive

Dieser Text wird gerade überarbeitet und ist in Kürze verfügbar.

Business Model Canvas

Ihr Geschäftsmodell auf einen Blick

Der Business Model Canvas von Alexander Osterwalder ist ein populäres Tool zur Entwicklung, Dokumentation und Visualisierung von Geschäftsmodellen. Die wesentlichen Aspekte des Geschäftsmodells werden dabei in die unterschiedlichen Felder des Canvas überführt und zueinander in Verbindung gesetzt. Vor allem in einer frühen Phase der Konzeptentwicklung kann so eine Vollständigkeit aller wesentlichen Elemente sichergestellt werden. Gleichzeitig lassen sich die Wechselwirkungen von Anpassungen einzelner Elemente besser einschätzen, beispielsweise bei Business Innovation Projekten.

SCRUM

Planvoll Agil

SCRUM ist ein Framework, das im Kontext der agilen Softwareentwicklung entstanden ist, inzwischen jedoch in Projekten unterschiedlichster Art und Größe Anwendung findet. Seine Philosophie ist eng mit dem „Manifest für agile Softwareentwicklung“ verknüpft, das 2001 von einigen Softwareentwicklern publiziert wurde. Das Manifest definiert zentrale Werte einer zielführenden Softwareentwicklung und stellt diese in Gegensatz zur sonst üblichen Vorgehensweise. Im Manifest heißt es:

  • Individuen und Interaktion mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Diese Werte stellen nicht weniger als einen vollständigen Paradigmenwechsel zur bisherigen Form der Softwareentwicklung und des Projektmanagements dar. Das spontane Reagieren auf Veränderung wird für wichtiger erachtet als das dogmatische Abarbeiten eines detaillierten Planes. In vielen Organisationen stößt diese Philosophie auch heute noch auf große Skepsis. Zu groß ist die Versuchung, komplexe Projekte im Vorfeld bis ins Detail durchdenken zu wollen. Jede Eventualität und Abhängigkeit soll idealerweise vorab erkannt und berücksichtigt werden. Die hohe Zahl an gescheiterten IT-Großprojekten, die Kosten in Milliardenhöhe verursachen und dann ergebnislos eingestellt werden, sprechen nicht unbedingt für die Leistungsfähigkeit dieser Vorgehensweise.

Zu den Gründungsvätern dieser Bewegung gehörten auch Jeff Sutherland und Ken Schwaber, die heute als Erfinder der SCRUM-Methodik angesehen werden. Bereits 1995 schrieb Schwaber in einem Konferenzbeitrag:

Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität“ (Schwaber, 1995).

Scrum kennt drei wesentliche Rollen in der Softwareentwicklung und im Projektmanagement. Dies sind der Product Owner, der Scum Master und der Developer. Jede dieser drei Rollen hat klare Zuständigkeiten und Aufgaben, die erst im engen Zusammenspiel miteinander Sinn ergeben.

Rollen im SCRUM Framework

Product Owner

Die Aufgabe dieser Rolle liegt darin, die Anforderungen des Produktes zu definieren, zu priorisieren und mit anderen Stakeholder abzustimmen. Der Product Owner ist häufig auch für den wirtschaftlichen Erfolg des Produktes sowie dessen Budget verantwortlich. Die Anforderungen des Produktes werden üblicherweise als separate Punkte in einem Backlog dokumentiert und gemäß ihrer Priorität in den Entwicklungsprozess (Sprint) überführt. Im Gegensatz zu einem klassischen Projektleiter, der Aufgaben an andere Abteilungen delegiert, ist der Product Owner selbst Teil des Scrum-Teams und kann stärker Einfluss auf den Erfolg des Projektes nehmen.

Scrum Master

Diese Rolle hat einen starken Coaching-Charakter. Der Scrum Master ist als Befähiger des Teams zu betrachten. Er verfügt über keinerlei (disziplinarische) Befugnisse, sondern unterstützt das Team bei der Einführung und Anwendung des SCRUM Frameworks. Er kennt sich bestens mit dem Regelwerk aus, schult und moderiert die Scrum-Events oder vermittelt bei Unstimmigkeiten. Er sorgt auch gegenüber der Organisation dafür, dass das Team ungestört seiner Arbeit nachgehen kann.

Developer

Diese Rolle ist für die tatsächliche Umsetzung der Anforderungen in ein Produkt bzw. eine Funktionalität zuständig. Üblicherweise handelt es sich um ein ganzes Team von Developern, deren Bezeichnung nicht zwangsläufig für „Softwareentwickler“ stehen muss. In der Softwareentwicklung beinhaltet dieses Team üblicherweise auch Tester, Datenbankexperten, etc. Das Development Team schätzt den Entwicklungsaufwand für einzelne Funktionalitäten und plant diese gemäß ihrer Priorität in die kommenden Sprints ein.

Das Konzept des „Sprint“

Die Entwicklung von Funktionalitäten erfolgt im SCRUM innerhalb eines festgelegten Zeitabschnittes, der als Sprint bezeichnet wird. In dieser Zeit wird ein sogenanntes „Inkrement“ entwickelt, eine eigenständig verwendbare Funktionalität, die nach dem Sprint in die produktive Nutzung überführt werden kann.

Üblicherweise dauert ein Sprint vier bis sechs Wochen. Die Dauer wird vom Voraus festgelegt und nicht mehr verändert. Die Aufgaben für den jeweiligen Sprint werden ebenfalls im Voraus festgelegt und anschließend nicht mehr verändert. Der Sprint kann vom Product Owner abgebrochen werden, wenn wichtige Ereignisse die Erreichung des Sprint Zieles nicht länger ermöglichen.

Ereignisse im SCRUM Framework

Sprint Planning

Das Sprint Planning findet im Vorfeld eines neuen Sprints statt. In diesem Event stellt der Product Owner seine priorisiere Anforderungen aus dem Product Backlog vor. Anschließend werden diese vom Development Team in den Sprint Backlog überführt und hinsichtlich ihrer Komplexität geschätzt. Am Ende wird eine gewissen Anzahl an Anforderungen zur Umsetzung im kommenden Sprint verabschiedet und durch den Sprint Backlog dokumentiert. Das Development Team entscheidet hierbei, wie ein realistisches Ziel für den kommenden Sprint aussieht und wie viel Funktionalität tatsächlich umgesetzt werden kann.

Daily SCRUM

Das daily SCRUM findet als kurzes tägliches Meeting, gerne auch Standup genannt, statt. Es dient dem gegenseitigen Informationsaustausch. Die Mitglieder des Development Teams informieren sich gegenseitig, was seit dem letzten Daily erreicht wurde und was man sich bis zum nächsten Daily vorgenommen hat. Unerwartete Ereignisse, Verzögerungen und Abhängigkeiten etc. werden so schnell für alle Beteiligten transparent.

Sprint Review

Das Sprint Review findet am Ende eines Sprints statt. Das Development Team präsentiert das Inkrement des Sprints und gleicht dieses gemeinsam mit dem Product Owner gegen die initiale Planung und Zielsetzung ab. Der Product Owner begutachtet die entstandenen Funktionalität und überprüft, ob diese seinen Anforderungen und Qualitätskriterien entspricht.

Retrospektive

Die Retrospektive ist eine offene Aussprache am Ende des Sprints. Diese findet in einem geschützten Raum unter Ausschluss der übrigen Stakeholder statt. Sie zielt darauf ab, die künftige Zusammenarbeit zu verbessern und aufgetretene Probleme offen und ehrlich zu klären. Der Scrum Master moderiert dieses Meeting und unterstützt das Team bei der Definition von Verbesserungsmaßnahmen.

Artefakte im SCRUM Framework

Product Backlog

Das Product Backlog stellt eine Auflistung der künftigen Anforderungen und Funktionalitäten dar. Das Dokument wird ständig überarbeitet und angepasst, die enthaltenen Elemente werden (neu) periodisiert und ergänzt.

Sprint Backlog

Das Sprint Backlog enthält Anforderungen und Funktionalitäten, die als Inkrement im nächsten Sprint erarbeitet werden sollen. Es ist daher meist deutlich weniger umfangreich als das Product Backlog.

Scrum Prozess

OKR

Messbare Ziele setzen

Das Konzept der „Objectives and Key Results“, kurz OKR, geht auf die Arbeit von John Doerr zurück. Ziel der Methodik ist es, ein klares Framework zur Zielsetzung (Objectives) zu etablieren und die Erreichung dieser Ziele (Key Results) anhand klar definierter und gut messbarer Metriken zu ermöglichen.