Für uns beginnt es früher: in dem Moment, in dem wir versuchen, die Herausforderung hinter einer Anfrage wirklich zu verstehen.
Wer bei uns anfragt, hat intern meistens längst entschieden, dass etwas passieren muss: Eine neue Website wird gebraucht, ein Extranet soll abgelöst oder eine individuelle Anwendung entwickelt werden. Manche Teams denken darüber erst seit wenigen Wochen nach, andere begleitet das Thema seit Jahren.
Was viele von ihnen zunächst gemeinsam haben:
Sie möchten ein Angebot. Eine Zahl. Möglichst schnell.
Das ist verständlich. Budgets müssen geplant und Anbieter verglichen werden. Trotzdem geben wir nur selten direkt ein Angebot für das eigentliche Projekt ab. Denn eine schnelle Zahl wäre zu diesem Zeitpunkt häufig vor allem eines: geraten.
„Wir benötigen ein neues Extranet“ klingt zunächst eindeutig. Doch welche Aufgabe erfüllt das bestehende System? Wer arbeitet damit? Welche Funktionen sind unverzichtbar – und welche gibt es nur noch, weil es sie schon immer gab? Welche Prozesse und Schnittstellen hängen daran? Woran erkennen die Beteiligten später, dass das Projekt erfolgreich war?
Natürlich könnten wir trotzdem einen Preis aus Annahmen ableiten. Wenn diese Annahmen nicht gemeinsam überprüft wurden, verlagert man die Unsicherheit jedoch nur in das Projekt. Später wird dann über Erwartungen, Verantwortlichkeiten und Nachträge diskutiert.
Das halten wir nicht für sinnvoll.
Um diese Unsicherheit früh zu bearbeiten, haben wir vor mehr als zehn Jahren ein Format entwickelt, das wir seitdem kontinuierlich weiterentwickeln: unseren Punktlandungsworkshop.
Der Name beschreibt den Ablauf ziemlich gut. Zunächst gewinnen wir Höhe und erweitern den Blick. Danach setzen wir zur Landung an.
Begleitet wird er in der Regel von unseren Berater:innen – häufig von Marco oder mir. Je nach Thema kommen Product Owner:innen, Designer:innen oder UX-Strateg:innen hinzu. Kein Workshop ist exakt wie der andere.
Der Vormittag gehört dem Verstehen. Wir lernen das Unternehmen, seine Ziele und die Geschichte des Projekts kennen. Wir betrachten Zielgruppen, Prozesse, technische Rahmenbedingungen und mögliche Entwicklungen. Dabei fragen wir auch nach Dingen, die zunächst außerhalb des geplanten Projekts liegen. Nicht, um es größer zu machen, sondern um wichtige Zusammenhänge nicht zu übersehen.
Am Nachmittag verdichten wir die Ergebnisse: Wir sortieren Funktionen, besprechen Ausbaustufen und setzen erste Prioritäten. Was gehört in eine erste Version? Was kann später folgen? Wo brauchen wir noch Konzeption?
Wenn die Aufgabe kleiner ist als gedacht und nach vier Stunden Klarheit besteht, sind wir früher fertig. Bei einem über Jahre gewachsenen System benötigen wir vielleicht länger.
Entscheidend ist nicht die Dauer. Entscheidend ist, dass beide Seiten anschließend dasselbe Projekt vor Augen haben.
Nach dem Workshop erstellt die verantwortliche Person gemeinsam mit einem passenden Scrum-Team das Strategiepapier. Wir verlassen uns hier nicht auf KI sondern prüfen die Erkenntnisse durch Menschen, die das Projekt später umsetzen könnten.
Das Strategiepapier verbindet typischerweise vier Bereiche:
Das Angebot ist also kein separates Preisschild, sondern Teil einer nachvollziehbaren Empfehlung. Dieses Papier präsentieren wir und entwickeln es mit dem Kunden weiter. Meist empfehlen wir eine klare Route. Grundlegend unterschiedliche Varianten zeigen wir nur, wenn sie für die Entscheidung wirklich relevant sind.
Auch darin zeigt sich unsere spätere Arbeitsweise: Wir verschwinden nicht mit den Anforderungen und kommen mit einem unveränderlichen Ergebnis zurück. Wir machen unseren Vorschlag sichtbar, holen Rückmeldung ein und schärfen ihn gemeinsam.
Wie tief wir dabei in die Welt eines Kunden eintauchen, zeigt unsere Zusammenarbeit mit der FEGIME Deutschland. Ihr individuell entwickeltes Extranet war über 15 Jahre gewachsen. Einige Funktionen wurden nicht mehr benötigt, andere waren für die Marktgemeinschaft unverzichtbar. Das System bildete nicht nur Technik ab, sondern auch Abläufe, Wissen und zahlreiche frühere Entscheidungen.
In einem zweitägigen Workshop haben wir das Vorhaben gemeinsam mit dem langjährigen IT-Ansprechpartner auseinandergenommen. Sein tiefes Wissen über Organisation, Nutzer:innen und Prozesse traf auf unsere Außenperspektive und Erfahrung mit komplexen Digitalprojekten. So konnten wir entscheiden, was bewahrt, entfernt oder neu gedacht werden sollte.
Das ist für uns Einarbeitung: nicht nur eine Funktionsliste aufnehmen, sondern das Unternehmen hinter dem System kennenlernen. Wie daraus ein MVP und ein schrittweiser Continuous Relaunch entstanden, zeigt unsere Case Study zum FEGIME-Extranet.
