Auf den Trichter gekommen

Der (an der dieser Stelle nicht näher spezifizierte) Business liebt seine Trichter, äh, ich bitte um Entschuldigung, Funnel natürlich. Sales Funnel, Conversion Funnel, Knowledge Funnel, Product Funnel. Für alles, was man so machen kann, gibt es einen Funnel. Und diese Trichter (nichts anderes heißt Funnel ja) leisten wahnsinnig tolle Arbeit. Man kippt oben einfach alles völlig unsortiert rein und unten purzeln nur noch genau die Dinge in der richtigen Menge raus, die man haben möchte. Verzehrfertig, sozusagen.

Da fallen einem natürlich sofort mehrere Dinge ins Auge. Vor allem, dass das nicht das ist, was ein Trichter so tut. Im Gegenteil, das ist das Gegenteil von der Aufgabe eines Trichters. Der soll schließlich Grobmotorikern wie mir helfen, Flüssigkeiten, Pulver und ähnliches Gedöns möglichst verlustfrei von einem Behältnis in ein anderes zu Füllen. Vom Topf in die Flasche. Von der Zapfsäule in den Kanister. Vom Bierfass in die Studierenden.

So ein Funnel macht aber was anderes. Der macht Dinge kompakt, und vor allem sortiert er aus. Also arbeitet er eigentlich viel mehr wie ein Filter oder ein Verdichter. Oder beides. Das simple Bild vom Trichter wird dem nicht gerecht. Und vielleicht funktionieren Funnel deshalb auch nicht so selbstverständlich, wie man uns das immer gerne weiß macht. Funnel sind Arbeit. Richtig viel Arbeit.

Für Marketing und Co kann ich das nur so halb beurteilen. Da bin ich (maximal) interessierter Laie und das können euch Marketingexpert:innen viel besser auseinandernehmen.

Aber Projekte, Information, Ressourcen und Werkzeuge, damit kenne ich mich aus.

Und auch die haben einen Funnel. Einen so wichtigen Funnel, dass sich eigentlich alles darum drehen sollte, wie der funktioniert. Leider wird aber genau das nur allzu gerne ignoriert. Und so wird aus dem Funnel im besten Fall oft eine Pipeline, und im schlimmsten ein Fallrohr. Aber von vorn:

Im großartigen Buch Software Estimation: Demystifying the Black Art von Steve McConnell (ein zeitloses Meisterwerk übrigens, das bei allen in dem Bereich tätigen Entscheider:innen, von Architektur über Projektmanagement bis Product, eigentlich immer unter dem Kopfkissen liegen sollte) beschreibt Steve den sogenannten Cone of Uncertainty. Also einen Kegel, der mit ganz viel Ungewissheit beginnt und hoffentlich mit sehr viel Gewissheit und einem Projekterfolg endet. Und beginnen tut er, natürlich, mit dem Start des Projekts. Vielleicht gibt es hier schon eine Vision des Produkts, vielleicht ein konkretes Ziel, vielleicht hat ein Agent schon was gebaut was dem Management Applaus entlockt.

Aber auf die eigentlich wichtigen Fragen liefert das keine Antwort. Weder auf die harten Fragen wie „wann fertig?“ oder „wie teuer?“, noch auf die noch viel wichtigeren Fragen wie „löst es das Problem?“ oder, noch besser, „was ist das Problem?“. In diesem konkreten Kontext heißt das, dass wir diese Fragen natürlich zu Beginn schon stellen können; wir können nur nicht erwarten, eine brauchbare Antwort darauf zu bekommen. Die wird erst einmal unscharf sein, denn wir stehen ja erst am Anfang. Eigentlich sind wir da noch naiv und dumm. Über die Zeit wollen wir das ändern. Mindestens auf naiv und schlau. Aber noch besser auf gewieft und schlau.

Und im Grunde (sorry, lieber Mathehasser) machen wir hier Statistik. Wir schätzen, und wie es sich für eine gute Gauß-Verteilung gehört, liegen wir mit einer gewissen Wahrscheinlichkeit daneben. Je breiter der Kegel, desto breiter und flacher auch der Huckel unserer statistischen Verteilung. Und wenn wir ganz am Anfang stehen, ist der halt flach wie die norddeutsche Tiefebene. Jede Antwort ist möglich, und fast jede Antwort wird falsch sein.

Damit unsere Antworten besser werden, brauchen wir Infos. Das heißt erstens, wir müssen mehr in Erfahrung bringen, wir müssen konkreter werden, das Rauschen aus dem, was die Leute so über das Projekt und seine Ziele sagen, muss weg. Und das bedeutet natürlich, jemand muss Entscheidungen treffen. Am besten wohlinformierte, das heißt, ein tiefes Verständnis muss ebenso da sein wie der Wille, Dinge festzulegen. Das ist oft unangenehm, denn naja, damit legen wir uns ja fest und wer will das schon. Wir nehmen uns Bewegungsspielraum weg. Und das oft genug in Arealen, wo wir noch gar nicht wissen, wie schnell und vor allem wohin wir uns bewegen sollen.

Hinzu kommt, Menschen sind oft nicht so gut darin, zu sagen, was sie wollen. Oft genug, weil sie zu Beginn eines Projekts nur glauben, das beurteilen zu können. Sie sind aber glücklicherweise recht gut darin zu sagen, was sie nicht wollen. Und das machen wir uns in diesem Fall auch zu Nutze. Wenn alles verrauscht (also zufallsverteilt) ist zu Beginn eines Projekts, dann greifen wir doch einfach mal wahllos Dinge heraus und holen uns Feedback dazu.

Klassische Prozesse tun sich damit schwer, deshalb sind wir irgendwann auf den Trichter (Hah!) mit der Agilität gekommen. Schnelle Prototypen, schnelle Feedbackschleifen. Und damit auch frühe Ausschlusskriterien. Im KI-Zeitalter bringen wir das sogar auf Lichtgeschwindigkeit, da machen wir keine wochenlangen Design Sprints mehr, da arbeiten wir gemeinsam live am Clickdummy oder Prototypen. Weil wir’s können.

Und so machen wir Schritt für Schritt den Kegel enger. Jede Entscheidung, jede Erkenntnis verringert die Unsicherheit, macht die Standardabweichung unserer Gauß-Verteilung kleiner; der Fehler unserer Schätzungen wird kleiner, denn wir werden viel konkreter.

Wohlgemerkt aber nur, wenn wir wirklich den Kegel durch unsere Taten und Entscheidungen verengen.

Wie ein Business Funnel ist auch der Projektkegel kein Selbstläufer. Jedes „ich will mich noch nicht festlegen“ blockiert den Verdichtungsprozess, jedes „ich habe mich umentschieden“ pustet den Kegel wieder auf. Und damit sind wir dann auch wieder zurück in der harten Welt realer Projekte. Das sind unsere Projekte keine Kegel, sie sind oft genug Rohrversatzstücke, mal dünner, mal ausladender, die man (oft mit viel Panzertape) aneinander flanscht. Und wie es sich für Rohre und Durchfluss gehört, wird die Fließgeschwindigkeit auch gefühlt schneller, wenn das Rohr mal weniger Durchmesser hat. Alles fluppt besser, und weil es konkrete Ziele gibt, steuert man genauer auf diese zu und erreicht sie auch, mindestens gefühlt, aber oft auch real, schneller. Kommt dann aber wieder ein größeres Rohr, lässt das schlagartig nach.

In vielen Projekten ist das Realität. Und einher geht das nicht nur mit einem gewaltigen Berg an Frustration (für alle), sondern auch mit Endergebnissen, die sich nur mit viel Fantasie noch als Projekterfolg verkaufen lassen.

Projektmanager:innen die keinen Bock auf Beef haben, aber organisatorisch auch nicht so viel bewegen können, versuchen mit Controlling zumindest den Rohrdurchmesser gleich zu halten. Das macht den Projekterfolg nicht wirklich wahrscheinlicher, aber immerhin ist das gut fürs Risikomanagement, denn damit gewinnt man an Vorhersagbarkeit. Man hat eine Vorstellung davon, dass es nicht so gut läuft. Das ist meiner Meinung auch übrigens das Äußerste, was dir die weit verbreitete Pseudoagilität (von SCRUM für Arme bis SaFE) so bringen kann. Mehr ist nicht drin. Oder ein Zufallstreffer.

Wer einen echten Projektkegel haben möchte, der gegen Projektende so scharf zuläuft, dass nur noch ein Projekterfolg herauskommen kann (oder der dazu führt, dass man sich eine Menge Geld und Frust spart, weil man sehr früh erkennt, dass das Projekt sinnfrei ist), der wird um die harte Realität agiler Methodiken mit all ihrer Transparenz und Stringenz nicht herumkommen. Ja, mehr noch, ich glaube sogar, dass in diesem Fall vielleicht sogar ein Wechsel der Methodik und der Werkzeuge irgendwann zwingend notwendig für ein sauberes Fortschreiten des Projekts ist.

Gestartet wird mit Methoden, die dem Erkenntnisgewinn und der Schärfung der Ziele dienen. Wir haben eine niedrige Informationsdichte, und das müssen wir ändern. Wir brauchen also Werkzeuge, die Information liefern und die es leichter machen, auf deren Basis auch sinnvolle Entscheidungen zu treffen. Hier glänzen Time-Boxed-Methoden mit strikten Ritualen wie Scrum, DSDM, XP und co. Wenn ich völlig planlos bin, geht dem vielleicht auch noch eine Phase mit Design Thinking oder ein Design Sprint voraus. Sprints treiben nicht einfach das Projekt voran, sie dienen vor allem den Erkenntnisgewinn und der Verdichtung der Information. Mit jedem Sprint sind wir schlauer als vorher, konnten jede Menge Dinge verwerfen. Und haben auch schon handfeste Dinge in der Hand, über die wir reden und Feedback einholen können.

Ich glaube aber auch, dass dieser Ansatz ab einem gewissen Projektstand seinen Impuls verliert. Wenn die großen Entscheidungen erst einmal alle getroffen sind und wir das Ziel auf der Landkarte gut kennen, dann verlagern sich Entscheidungen in die Details.

Und dann ist irgendwann jede Time-Box zu lang, um noch zügig voranzukommen. Wer dann partout noch an Scrum festhalten will, kann natürlich die Time-Boxen immer weiter verkleinern. Gepaart mit der Ritualistik von Scrum wird das aber irgendwann nicht mehr tragbar. Eigentlich ist dann die Zeit für andere Vorgehensweisen gekommen. Will man agil bleiben, dann wäre etwas flussorientiertes (passend zu unseren Rohren, Flanschen und Kegeln) wie Kanban natürlich eine gute Wahl. Das ist kompromisslos in der Steuerbarkeit, und erlaubt gleichzeitig eine zügige Bearbeitung der Details. Ich glaube aber, dass auch ganz klassische Projektierungsmethoden bis hin zum Wasserfall hier ihre Stärken entfalten könnten, wenn man dies denn wollte.

Der Kegel der Ungewissheit bestimmt aber nicht nur die Methodik, er gibt uns auch gute Hinweise auf die geeigneten Werkzeuge. Denn mit dem schrumpfenden Kegeldurchmesser wächst die Gewissheit. Aus Statistik wird Determinismus. Und dem können Werkzeuge Rechnung tragen. Denn das explorative, was zu Beginn sehr wichtig war, wird im späteren Projektverlauf durch Verlässlichkeit und Überprüfbarkeit abgelöst. Zumindest dann, wenn mein Projektziel ein verlässliches Produkt oder Prozess sein soll.

Und damit schlage ich wieder die Brücke zur generativen KI, wer hätte das gedacht. Die darf in den frühen Phasen wirklich punkten, weil sie uns erlaubt, viele Dinge schnell auszuprobieren, Ansätze flott zu testen und im Zweifelsfall zu verwerfen. Das kann sie so gut, weil sie sich als stochastisches System sich natürlich perfekt in diese Projektphase einpasst. Zumindest mir geht es aber so, dass ich, je enger der Kegel wird, mehr klassische Ingenieurskunst und harte Überprüfbarkeit sehen will. KI muss hier wahrlich nicht abwesend sein. Aber ihre Ergebnisse müssen überprüfbar, ihre Risiken gut einschätzbar sein. Sie hat sich der Verlässlichkeit des Projekts und dem deteministischen Denken unterzuordnen und wird in diesen Phasen, falls sie noch eine Rolle spielt, eher zusätzlicher Prüfer, vielleicht sogar Zulieferer. Wenn sie aber ganz vorne mitspielen will, ist klar abgesteckt, was sie tut und was sie darf. Und das meiste, tja, das darf sie dann halt nicht.

Für erfolgreiche Projekte ist so ein Kegel oder Trichter also was sehr gutes. Für viele Geschäftsprozesse auch.

Auf den Trichter zu kommen, das allein reicht aber nicht. Man muss vor allem dafür sorgen, dass ein Trichter auch ein Trichter bleibt. Und das erfordert einiges an Arbeit und mitunter harte Entscheidungen. Nicht nur in der Produktentwicklung. Sondern überall da, wo getrichtert wird.