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?
Schon im ersten Termin stoßen wir meistens auf zwei oder drei Fragen, die sich nicht mal eben beantworten lassen. Das ist kein schlechtes Zeichen. Es zeigt, dass wir an den entscheidenden Stellen angekommen sind.
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.
Nimmt ein Kunde unseren Vorschlag an, passiert etwas, das ich gern ein Stück punkt.de-Magie nenne: Ein Team übernimmt Verantwortung für den Kunden – häufig über viele Jahre.
Das Wissen aus Kennenlernen, Workshop, Strategiepapier und Angebot fließt über standardisierte interne Prozesse in dieses Team. Der oder die Product Owner:in wird meist zur ersten operativen Ansprechperson. Aber der PO ist keine Trennwand zur Entwicklung. Wir planen bewusst ein Kennenlernen zwischen den Ansprechpartner:innen auf Kundenseite und den Entwickler:innen ein – meist remote, beim Kick-off je nach Projekt auch vor Ort.
Gemeinsam klären wir dann, was bereits zu Projektbeginn strategisch ausgearbeitet werden muss und welche Konzepte erst sinnvoll sind, wenn ihre Umsetzung ansteht. Unser Ziel: genug Klarheit für die Richtung und genug Beweglichkeit für das, was wir unterwegs lernen.
Unser Vorgehen hat eine Voraussetzung: Der Kunde muss Lust auf das Projekt und auf echte Zusammenarbeit haben.
Wir können viel abnehmen. Wie tief ein Kunde fachlich oder technisch mitdenkt, lässt sich je nach Projekt und Kapazität gestalten. Ein Modell funktioniert jedoch nicht: uns eine PDF zu übergeben und ein Jahr später eine fertige Lösung abzuholen.
Wir brauchen Wissen aus dem Unternehmen, Entscheidungen und iteratives Feedback. Kund:innen müssen dafür nicht jede technische Frage beantworten. Aber beide Seiten müssen Verantwortung für das Ergebnis übernehmen. Diese Erwartung sprechen wir lieber früh aus.
Viele vergleichbare Agenturen bringen die notwendigen technischen Fähigkeiten mit. Die Entscheidung fällt deshalb selten allein anhand einer Programmiersprache, eines CMS oder einer Featureliste. Sie fällt auch nach dem Gefühl, das in den ersten Gesprächen entsteht.
Das schönste Feedback, das wir nach einem Punktlandungsworkshop oder der Präsentation eines Strategiepapiers bekommen können, lautet sinngemäß: „Die verstehen, was wir sagen.“
Genau darum geht es uns. Wir möchten nicht nur Anforderungen protokollieren, sondern verstehen, warum sie existieren und wie sie zusammenhängen. Erst dann können wir einen Vorschlag machen, hinter dem wir als zukünftiges Projektteam stehen.
Ein gutes Angebot ist deshalb für uns nicht der Anfang einer Verhandlung über eine Zahl. Es ist das Ergebnis eines gemeinsamen Verständnisses – und der erste Schritt in eine Zusammenarbeit auf Augenhöhe.
Im zweiten Teil dieser Serie geht es darum, wie diese Zusammenarbeit im laufenden Projekt konkret aussieht: wie wir unsere Projektumgebung aufbauen, gemeinsam priorisieren, Aufgaben übergeben und für Budgettransparenz sorgen.
