Discovery & Delivery: erst das Problem, dann die Lösung

Bei Kunden und Dienstleistern gibt es die Tendenz, sich stark auf die Delivery-Aspekte von Projekten und digitalen Initiativen zu konzentrieren: ein möglichst schneller Lösungsentwurf und die anschließende Umsetzung der Lösung rücken in den Vordergrund. Dieser Ansatz ist jedoch bestenfalls für Situationen geeignet, in denen nicht nur eine angemessene Lösung, sondern auch das zugrunde liegende Problem offensichtlich sind. Diese Situationen entsprechen der Simple Domain des Cynefin Framework — der einzigen Domäne dieses Modells, in der Best Practices sinnvoll anwendbar sind.

Wirklich interessante Probleme fallen jedoch in der Regel nicht in diese Domäne. Beispiele für solch interessante Probleme sind die Entwicklung eines neuen Produkts, die Erschließung eines neuen Marktes oder der Versuch, die Conversion Rate einer Webseite wesentlich zu verbessern.

In diesen Situationen sind effektive Lösungen nicht offensichtlich erkennbar, sondern müssen mittels eines explorativen Prozesses iterativ und inkrementell entwickelt werden. Agile und schlanke Methoden bieten hierfür geeignete Ansätze, die mittlerweile auch von großen Teilen der Wirtschaft eingesetzt oder zumindest anerkannt werden.

Weniger verbreitet ist jedoch die Erkenntnis, dass in solchen Situationen in der Regel auch das zu lösende Problem nicht offensichtlich ist: vielmehr muss aus einer ersten vagen Idee im Rahmen von Discovery-Tätigkeiten eine effektive Problemdefinition entwickelt werden. Zu diesen Tätigkeiten gehören die Analyse unterschiedlicher Aspekte der zugrunde liegenden Situation, die Identifikation möglicher Probleme oder Chancen sowie die schlussendliche Auswahl des durch eine bestimmte Initiative zu lösenden Problems.

Auch in der Discovery kommen explorative Ansätze sowie ein inkrementelles, iteratives und interaktives Vorgehen zum Einsatz. Insbesondere kann die iterative Konkretisierung der Problemdefinition (z.B. auf Basis von ‚Experimenten‘ mit potenziellen oder tatsächlichen Kunden) sehr wirkungsvoll sein. Die Lean Startup Methode bietet hierfür effektive Ansätze.

Der Design Thinking Ansatz und das Double Diamond Modell des Designprozesses (sowie viele andere Designprozesse) beschreiben die Notwendigkeit solcher Discovery-Tätigkeiten im Designprozess (allerdings differenzieren sie feiner als ich das hier mit dem einfachen Discovery/Delivery-Modell tue).

Einige Dienstleister schalten den Delivery-Phasen ihrer Projekte mittlerweile eine Discovery-Phase vor. Dies ist begrüßenswert, aber noch nicht ausreichend. Um größtmöglichen Nutzen zu erzielen, muss Discovery auch auf detaillierteren Ebenen innerhalb eines Projekts zum Einsatz kommen, z.B. für einzelne Features oder Funktionen.

Die Entwicklung von Prototypen mittels geeigneter Prototyping-Werkzeuge (und nicht etwa mittels Softwareentwicklung) kann die Produktentwicklung erheblich verbessern und beschleunigen — mehr dazu in Prototyping ist Discovery-Arbeit.

Welche pragmatischen Ansätze gibt es, um Ihre Discovery-Praxis — und damit Ihre Leistung in der Produktentwicklung — zu verbessern? Sprechen Sie mich an, um erste Ideen zu diskutieren!

2 Gedanken zu „Discovery & Delivery: erst das Problem, dann die Lösung

  1. Pingback: Prototyping ist Discovery-Arbeit | Oliver Baier

  2. Pingback: Digitalisierung in mittleren Unternehmen und dem Mittelstand | Oliver Baier

Die Kommentarfunktion ist geschlossen.