Es gibt einen Satz, der in der Beratung — zumindest hierzulande — fast wie ein Fluch klingt. Eines jener Dinge, die du denkst, während du das nächste Meeting in einen Wunschzettel-Katalog verwandeln siehst, das du aber nicht aussprichst. Weil man das nicht macht, weil „die Kundenbeziehung“, weil der Vertrieb dich mit Blicken erlegt und dich jemand daran erinnert, dass „wir hier sind, um Bedürfnisse zu erfüllen“.
Und doch.
Der Kunde hat unrecht.
Nicht immer, klar. Nicht in allem. Aber viel öfter, als wir zugeben mögen. Ich frage mich, ob das eigentliche Problem nicht der Kunde ist, sondern die höfliche Lüge, die wir ihm seit Jahren erzählen. Die vom „Der Kunde hat immer recht“. Eine Lüge, die in der italienischen Software Schäden angerichtet hat, die niemand sauber zählen kann, weil Misserfolge selten ein Schild „Misserfolg“ tragen. Sie sind meist leiser. Es sind Projekte, die in Produktion gehen und die niemand nutzt. Es sind verbranntes Geld für Dinge, die nichts verbessern. Es sind lange Nächte von Menschen, die wussten, dass es schiefging — aber nicht den Raum oder die Erlaubnis hatten, es zu sagen.
Das ist ein etwas bösartiger Text, ja. Ich verlange nicht, dass ihr zustimmt. Ich verlange nur Ehrlichkeit, für die Dauer dieser Lektüre.
Das Ja, das Projekte tötet
Ich habe mehr Projekte an einem Ja sterben sehen als an einem Nein.
Der Mechanismus ist fast immer derselbe, und gerade deshalb beunruhigt er. Der Kunde verlangt etwas. Du weißt es, du fühlst es, du siehst es in den Details: Es ist technisch falsch, oder wirtschaftlich, oder als Richtung. Aber du sagst trotzdem Ja.
Du sagst Ja, weil es einen Vertrag gibt. Weil eine Beziehung zu schützen ist. Weil „wir richten das schon noch“. Weil der Handschlag schon erfolgt ist und Zurückrudern wie eine Niederlage wirkt. Weil Nein zu sagen unbequem ist, Argumente verlangt, Energie verlangt — und vor allem Mut.
Und so stirbt das Projekt nicht in einem Schlag. Es stirbt ein Ja nach dem anderen.
Jedes Ja fügt ein Feature hinzu, das niemand nutzen wird. Jedes Ja verschiebt ein Stück Deadline oder drückt ein Stück Qualität. Jedes Ja macht die Architektur etwas brüchiger und den Code etwas verschlungener, bis das, was du baust, kein Produkt mehr ähnelt, sondern einem geschichteten Kompromiss.
Am Ende lieferst du eine Software, die hundertfünfzig Dinge tut, keines davon gut, und der Kunde sieht dich an und sagt: „Das ist nicht, was ich wollte.“
Und hier brennt der Punkt, denn in gewissem Sinn hat er recht. Es ist nicht, was er wollte. Es ist, was er verlangt hat. Zwei verschiedene Dinge.
Und vielleicht ist unser eigentliches Handwerk nicht, Befehle auszuführen. Es ist, den Unterschied zu erkennen.
Katalog des Grauens (alle wahr, leider)
Was folgt, ist wahr. Die Namen sind geändert, die Dynamiken nicht. Und falls ihr denkt „so einen habe ich auch schon gesehen“, seid ihr nicht allein.
Die endlose ERP
Ein mittelgroßes Unternehmen verlangt eine ERP. So weit normal. Während der Entwicklung fügt jede Abteilung Anforderungen hinzu. HR will den Urlaubsmodul, Marketing das Dashboard, die Buchhaltung die Anbindung an den Steuerberater, und jeder hält sich für den Mittelpunkt der Welt.
Niemand hat die Macht, „Schluss“ zu sagen, weil jede Abteilung ein „interner Kunde“ ist, der „recht hat“. Ergebnis: achtzehn Monate Entwicklung, ein Produkt, das alles schlecht macht, und nach dem Release nutzt das Unternehmen weiter Excel. Das wenigstens, in seiner Bescheidenheit, niemanden verrät.
Die Copy-Paste-Ausschreibung
Eine Kommune muss einen Service digitalisieren. Die Ausschreibung wird abgeschrieben aus jener einer anderen Kommune, vielleicht dreimal so groß, mit völlig anderen Bedürfnissen. Hineingeraten Anforderungen, die auf dem Papier gut klingen, die aber kein Bürger jemals nutzen wird.
Wer den Auftrag gewinnt, weiß es oft. Aber die Ausschreibung ist die Ausschreibung. Also baut man genau das Geschriebene. Man liefert, prüft ab, hakt Kästchen ab. Die Plattform geht online.
Sechs Monate später wird der Service immer noch am Telefon abgewickelt.
Das Traurigste: Formell ist alles gut gelaufen.
Die App, die alles ändern sollte
Eine lokale Verwaltung will eine Mobile-App für die Bürger. Der Entscheider ist ein Stadtrat, der die App einer anderen Kommune gesehen hat und sie genauso will. Keine Bedarfsanalyse, keine Nutzerforschung, nichts. Nur: „Ich will die App.“
Der Anbieter baut sie. Beim Launch laden sie vierhundert herunter. Drei Monate später nutzen zwölf sie, die Kommunemitarbeiter mitgezählt.
Der Stadtrat hält die Pressekonferenz und spricht von Innovation. Der Anbieter kassiert und geht zum nächsten.
Und ich kann mich nie entscheiden, wer mir in der Geschichte am meisten Unbehagen bereitet.
Das Restyling, das eine Neuschreibung war
Ein Kunde verlangt, die Site „aufzufrischen“. Der Vertrieb verkauft ein Restyling. Bei der ersten operativen Sitzung kommt heraus: Die Site hat kein CMS, die Datenbank ist eine Excel-Datei, die Inhalte existieren nicht, und „Auffrischung“ bedeutet, die ganze digitale Präsenz neu zu denken.
Aber das Angebot ist das eines Restylings, die Timeline ist die eines Restylings, und die Erwartungen sind die eines Restylings.
Alle wissen, dass es kein Restyling ist. Niemand sagt es.
Das Zombie-Projekt
Ein Projekt sollte sechs Monate dauern und tritt ins dritte Jahr ein. Es funktioniert nicht, wird nicht genutzt, aber niemand schließt es, weil das hieße, einen Fehler einzugestehen.
Der Kunde zahlt weiter Change Requests. Der Anbieter fakturiert weiter. Beide wissen, es ist tot. Beide tun, als lebte es.
Es scheitert nie offiziell. Es hört einfach auf, in Sitzungen erwähnt zu werden, wie ein unangenehmer Onkel, von dem man bei Tisch nicht spricht.
Warum es wirklich passiert
Es passiert, weil unsere Branche ein strukturelles Problem mit der Wahrheit hat.
Das Geschäftsmodell der italienischen IT-Beratung ist auf dem Ja gebaut. Du gewinnst Projekte mit Ja. Du behältst Kunden mit Ja. Du machst Karriere mit Ja. Das ganze System, vom Vertrieb über die Projektleitung bis zu den Entwicklern, ist optimiert, um Konflikt zu minimieren und kurzfristige Fakturierung zu maximieren.
Das Problem: Kurzfristig und langfristig liegen im Krieg.
Heute Ja zu sagen heißt fast immer, morgen zu zahlen. Jedes zusätzliche Feature ist technische Schuld. Jede ohne Analyse akzeptierte Anforderung ist eine Zeitbombe. Jede gestauchte Timeline, um jemandem zu gefallen, ist eine Garantie für Überstunden, oft unbezahlt, und für geopferte Qualität.
Und derweil lernt der Kunde nie. Nicht weil er dumm wäre, sondern weil ihm niemand sagt, dass diese Anfrage falsch war. Niemand sagt ihm, dass diese Ausschreibung schlecht geschrieben war. Niemand sagt ihm, dass diese App niemandem nützte.
Umringt von Nickenden, fragt der Kunde weiter dieselben falschen Dinge, und der Kreis beginnt von neuem.
Hier kommt der Teil, der stört, weil er die Verantwortung verschiebt.
Es ist nicht die Schuld des Kunden. Es ist unsere Schuld.
Es ist die Schuld einer Branche, die ihre Rolle aufgegeben hat — die der Expertin. Jener, die Dinge weiß, die der Kunde nicht weiß, und die die Pflicht — nicht das Recht — hat, sie zu sagen.
Das Nein als Dienst
Der beste Dienst, den du einem Kunden erweisen kannst, ist Nein zu sagen.
Nein, dieses Feature ist nicht nötig.
Nein, diese Timeline ist nicht realistisch.
Nein, diese Ausschreibung ist schlecht geschrieben, und wenn wir sie wörtlich befolgen, bauen wir etwas Nutzloses.
Nein, du brauchst keine App.
Nein, du brauchst keine KI.
Nein, du brauchst kein Restyling. Du brauchst innezuhalten und zu verstehen, was du wirklich tun willst.
Jedes Nein kostet. Es kostet Unbequemlichkeit, es kostet Spannung, es kostet ein paar harte Telefonate. Manchmal kostet es das Projekt.
Aber jedes Nein ist auch ein Akt des Respekts gegenüber dem Kunden, weil es ihn als Erwachsenen behandelt, der die Wahrheit hören kann — nicht als jemanden, dem zur Beruhigung zuzustimmen ist.
Die besten Kunden meiner Karriere sind die, denen ich am meisten Nein gesagt habe. Anfangs versteifen sie sich, ganz normal. Wenn du dann standhältst und ruhig argumentierst, geschieht etwas: Sie verstehen, dass dein Ja, wenn es kommt, glaubwürdig ist.
Vertrauen baut sich nicht auf ständigem Einverständnis. Es baut sich auf Aufrichtigkeit.
Und Aufrichtigkeit ist in unserer Branche selten. Vielleicht seltener als ein guter Entwickler. Vielleicht seltener als ein pünktlich geliefertes Projekt. Vielleicht seltener als eine gut geschriebene Ausschreibung.
Ein minimales Manifest, ohne Heldentum
Ich weiß nicht, ob das ein Manifest ist, aber wenn doch, passt es für mich in drei Zeilen.
Sag nicht Ja, wenn du weißt, dass es Nein ist.
Bau nicht, was der Kunde verlangt, wenn du weißt, dass es nicht ist, was er braucht.
Und wenn du dich irrst — denn du wirst dich irren, und wir alle werden uns irren —, irre dich wenigstens, indem du die Wahrheit sagst, nicht indem du nickst.
Der Kunde hat nicht immer recht. Aber er verdient immer jemanden, der den Mut hat, es ihm zu sagen.
Was du mitnimmst
Jedes Ja fügt technische Schulden hinzu, drückt Qualität und bereitet das abschließende „Das ist nicht, was ich wollte“ vor.
Vertrauen baut sich nicht auf ständigem Einverständnis auf, sondern auf Aufrichtigkeit: Wenn du Ja sagst, kann man dir glauben.
Aufrichtigkeit ist in unserer Branche seltener als ein guter Entwickler oder eine gut geschriebene Ausschreibung.
Fragen & Antworten
Warum tötet das ständige Ja zum Kunden Beratungsprojekte?
Weil der Kunde oft eine Lösung formuliert, wo er ein Problem formulieren sollte. Ja zu „Ich will eine Mobile-App“ zu sagen, wenn das echte Problem lautet „Meine Vertriebler verlieren Zeit beim Ausfüllen von Berichten“, heißt das Richtige für das falsche Problem zu bauen. Das automatische Ja liefert das verlangte Projekt, nicht das nötige — und sechs Monate später gilt der Berater als schlecht, nicht das schwache Briefing.
Wie sagt man konstruktiv Nein?
Indem man die Teile trennt. „Nein zu dieser Lösung, ja zum darunterliegenden Problem, schauen wir gemeinsam die Alternativen an.“ Der Kunde will nicht nur Nein hören — er will wissen, dass du verstanden hast, was er braucht, und dass du seine Investition vor seiner eigenen ersten Intuition schützt. Das nackte Nein ist arrogant; das „Nein + hier ist der Grund + hier ist mein Vorschlag“ ist Service.
Ist es im Wettbewerb nicht riskant, Nein zu sagen?
Kurzfristig wirkt es riskant, mittelfristig ist es das Gegenteil. Ernsthafte Kunden erinnern sich an jene, die sie vor einer ihrer Fehlentscheidungen gerettet haben — und kommen wieder. Kunden, die nur nach Ausführenden suchen, die zu allem Ja sagen, sind oft die schlimmsten, mit denen man arbeiten kann, weil das Projekt schlecht endet und sie die Verantwortung abwälzen. Frühes Nein zu filtern ist häufig der wirksamste Weg, die richtigen Kunden zu gewinnen.
Wo wird das Nein problematisch?
Wenn es zur Identität wird statt zur Dienstleistung. Eine Beraterin, die zu allem Nein sagt, um sich abzuheben, ist genauso nutzlos wie eine, die zu allem Ja sagt. Die Disziplin lautet: Ja, wenn der Kunde recht hat, Nein, wenn er nicht recht hat — und den Unterschied so zu erklären, dass er ihn beurteilen kann. Das verlangt mehr Kompetenz, mehr Zeit, mehr Respekt — alles Dinge, die fehlen, wenn man im T&M-Modell skaliert.