Smart Hacks für IT Projektmanager

Sidekick Network

Since 12/2024 15 Episoden

Projekterfolg ist Haltungssache

Warum Ehrlichkeit, Menschlichkeit und gute Fragen wichtiger sind als jedes Tool

17.02.2026 19 min

Zusammenfassung & Show Notes

In dieser Episode von SmartX für IT-Projektmanager spricht Gastgeber Andreas Weller mit Andreas Wey über die wahren Erfolgsfaktoren großer IT-Projekte. Die zentrale These: Projekte scheitern selten an fehlenden Tools – sondern an fehlender Ehrlichkeit, mangelnder Menschlichkeit und zu wenig kritischem Hinterfragen.

Andreas Wey beschreibt, warum er bereits im ersten Gespräch bewusst offenlegt, welche Kompetenzen er abdeckt – und welche nicht. Diese Transparenz schafft Vertrauen und verhindert spätere Eskalationen. Statt sich als „Alleskönner“ zu verkaufen, setzt er auf realistische Erwartungshaltung und klare Kommunikation.

Ein weiteres Kernthema ist die sogenannte Planning Fallacy: Projekte werden im Best Case geplant, Risiken ausgeblendet, Fachabteilungen nicht ausreichend eingebunden. Andreas Wey berichtet, wie er Aufwandsschätzungen validiert, mit Umsetzern spricht und notfalls frühzeitig Scope oder Timeline korrigiert – auch wenn das bedeutet, 100 % mehr Projektlaufzeit zu verhandeln.

Besonders eindrücklich ist sein Praxisbeispiel aus einem Versicherungsprojekt: Eine Beta-Software scheiterte zunächst vollständig. Durch offene Kommunikation („Gang nach Canossa“), Neuplanung und zusätzliche Investition konnte das Projekt dennoch erfolgreich abgeschlossen werden – mit nachhaltiger Akzeptanz bei den Anwendern.

Im Anforderungsmanagement plädiert er für moderierte Dialoge statt E-Mail-Pingpong. Bei konkurrierenden Requirements bringt er Stakeholder bewusst an einen Tisch. Sein Credo: Verständnis entsteht im Gespräch, nicht im Verteilen von Prioritätenlisten.

Auch beim Thema Change Management setzt er auf Pragmatismus: In einem Transformationsprojekt (Legacy-System → Web-App) schlugen zunächst Welten aufeinander. Die Lösung: Mock-ups statt PowerPoint. Visuelle Prototypen halfen, Brücken zwischen Entwicklern und Fachseite zu bauen – noch bevor produktiver Code geschrieben wurde.

Seine Quintessenz:

Methoden sind notwendig, aber nicht hinreichend. Der entscheidende Hebel ist der Mensch. Wer fragt, zuhört und Beziehungen aufbaut, erhöht seine Erfolgswahrscheinlichkeit signifikant.

Sein praktischer „Smart Hack“ zum Mitnehmen:
Investiere Zeit in echte Gespräche – geh mit deinem Kunden einen Kaffee trinken. Die Rendite kommt zurück.

📢 Episode: Projekterfolg ist Haltungssache – Warum Ehrlichkeit, Menschlichkeit und gute Fragen wichtiger sind als jedes Tool

🎙 Gast: Andreas Wey – IT-Projektmanager & Experte für komplexe Transformationsprojekte
🎙 Host: Andreas Weller – Managing Partner Sidekick Network

🎯 Thema:
Warum große IT-Projekte nicht an Technologie scheitern – sondern an fehlender Ehrlichkeit, mangelnder Menschlichkeit und zu wenig kritischem Hinterfragen. Wie du mit klarer Haltung, realistischer Planung und echtem Stakeholder-Dialog Projekte erfolgreich steuerst.

🔍 In dieser Episode erfährst du:

✅ Warum Projekte oft an der „Planning Fallacy“ scheitern
✅ Weshalb Ehrlichkeit im Vorstandsgespräch langfristig erfolgreicher ist als Selbstvermarktung
✅ Wie du mit unrealistischen Zeitplänen professionell umgehst
✅ Warum Anforderungsmanagement mehr Moderation als Priorisierung ist
✅ Wie du konkurrierende Stakeholder an einen Tisch bringst
✅ Warum Menschlichkeit in Großprojekten ein strategischer Hebel ist
✅ Wie ein gescheitertes Beta-Projekt durch Offenheit doch noch erfolgreich wurde
✅ Warum „in time & budget“ trotzdem komplett am Bedarf vorbeigehen kann
✅ Wie Mock-ups Brücken zwischen Legacy-Denken und moderner Entwicklung bauen
✅ Welcher analoge Smart Hack deine Projektarbeit sofort verbessert

📌 Highlights & Kapitelmarken:

⏳ [03:26] – Intro & warum Haltung wichtiger ist als Tools
🎯 [04:23] – Die drei Erfolgsfaktoren: Ehrlichkeit, Menschlichkeit, Fragen
🗣 [04:53] – Ehrlichkeit im Vorstandsgespräch – Erwartungsmanagement richtig gemacht
📉 [06:34] – Planning Fallacy & realistische Projektplanung
🧩 [08:56] – Anforderungsmanagement & konkurrierende Requirements
🤝 [10:53] – Menschlichkeit als Erfolgsfaktor in Großprojekten
🔥 [12:57] – Eskalation im Versicherungsprojekt & 100 % Laufzeitverlängerung
❓ [14:30] – Mehr fragen als nötig: Warum „perfekt geliefert“ trotzdem falsch sein kann
🖥 [16:31] – Legacy-System vs. Web-App: Mock-ups als Gamechanger
☕ [19:18] – Der praktische Hack: Kaffee trinken statt nur Status-Meeting

🎧 Jetzt anhören & Projekte menschlicher führen!

🔔 Folge uns, um keine Episode zu verpassen!

Mehr Infos zu Andreas Wey: https://www.linkedin.com/in/andreas-w-23183029/
Mehr Infos zu Andreas Weller: https://www.linkedin.com/in/andreas-weller-a68ba31/
Mehr Infos zu Sidekick Network: https://www.linkedin.com/company/sidekick-network/

Transkript

Hallo und herzlich willkommen bei SmartX für IT-Projektmanager. Präsentiert von Sidekick Network, basiert unser Podcast auf der Erfahrung von über 20. 000 IT-Projekten. Bist du bereit, direkt zum Punkt zu kommen? Dann lass uns starten. Wir sprechen heute darüber, warum Projekte häufig an fehlender Haltung, Ehrlichkeit und Menschlichkeit scheitern, nicht nur an Tools und Technologien. Vor allem in großen IT-Projekten werden Zeitpläne meist im Best Case präsentiert und vereinbart. Mögliche Probleme werden nur sehr wenig angesprochen und eingeplant. In der Realität sieht das zumeist anders aus, aber wie damit umgehen? Ich freue mich sehr, dass wir heute Andreas Wei zu Gast haben, der jeden Tag genau mit diesen Herausforderungen arbeitet. Hallo Andreas, wenn du auf deine Projekte schaust, was entscheidet dort wirklich über Erfolg oder Misserfolg aus deiner Sicht? Hallo Andreas. Schön, dass ich da sein darf. Ja, zu deiner Frage: Für mich das Wichtigste ist Ehrlichkeit, also wirklich zu sagen, wie Dinge sind, die Menschlichkeit auf den Menschen einzugehen und alles zu hinterfragen, was aufkommt. Ja, also diese drei Themen sozusagen. Lass uns die mal nacheinander aufteilen und vielleicht mit Ehrlichkeit rein steigen. Was bedeutet Ehrlichkeit für dich im Projektfeld konkret? Das fängt für mich schon beim Vorstandsgespräch an. Das heißt, wenn ich so eine Projektbeschreibung bekomme, dann decke ich meistens 80% ab. Selten alles. Ist ja Das ist eine sehr große Anforderung. Ja, das sind meistens fantasievoll große Anforderungen, aber ich sage das dann auch dem Kunden. Ich sage: „Das und das und das kann ich. Da habe ich zig Jahre Erfahrung. Das Thema habe ich einmal bestreift oder das Thema kenne ich überhaupt nicht. Und damit komme ich eigentlich immer gut an. Das Feedback sagen auch die Kunden. Sie fanden das sehr offen, das Gespräch, sodass sie auch genau wissen, was sie erwarten können von mir. Und wenn ich dann im Projekt bin tatsächlich und dann mit dem Thema zu tun habe, das ich halt vorher nicht kannte, dann habe ich eben auch ein bisschen Spielraum. Dann kann ich dem Kunden auch sagen: „Ich brauche jetzt ein bisschen länger. Ich kann das System ja schließlich nicht. Und der wusste das vorher auch. Also du bist nicht als Blender reingegangen und hast gesagt, du kannst alles, sondern hast eigentlich ein bisschen Bist du ein bisschen Risiko eingegangen im Gespräch, weil dann klar ist, okay, der ist wenigstens ehrlich und da kann ich mich drauf verlassen, dass der mir immer die Ehrlichkeit gibt, die ich brauche für mein Projekt? Ja, das ist ein Weg, das zu sehen. Es schützt mich aber auch hinterher, weil wenn ich jetzt behaupte, ich kann alles, der Kunde sagt: „Super, ich habe den Supermann gefunden und ich bin dann im Projekt und er erwartet, dass ich das alles kenne, auch die Themen, die ich in Wirklichkeit nicht kenne, dann sitze ich da und schwitze. Und früher, später findet er das raus. Und im schlimmsten Fall fliege ich dann aus dem Projekt. Da habe ich nichts gewonnen. Dann möchte ich die Zusage vorher nicht haben, wenn er sagt, ich will die 100%. Ich hatte ja Wir haben im Intro angesprochen, dass in den großen IT-Projekten meist im Best Case präsentiert und vereinbart wird. Was ist deine Erfahrung damit, wie man damit umgeht? Meistens kommt man sogar schon ins Projekt rein und kriegt gesagt, das läuft zwölf Monate. Genau, das ist schon klar. Das hat man vorher sich überlegt, was man da haben will. Ich gehe dann hin, gucke mir dann trotzdem mal den Scope an, was soll da eigentlich gemacht werden? Und ich rede dann auch mit einer der ersten Gesprächen mit den einzelnen Beteiligten, die da was bauen müssen, Datenbankleute, Netzwerkleute, Programmierer, und gucke, ob diese Aufwandsschätzung irgendwie zusammenpassen. Und oft genug tun sie das eben nicht. Entweder hat man gar nicht mit den Menschen die das umsetzen, oder man hat deren Best Case angenommen, dass sie am schnellsten irgendwo durchkommen. Ich rechne jetzt das Ganze zusammen im Projektplan und stelle das dann meinem Projektsponsor vor und sage ihm, inwieweit seine Idee zu optimistisch ist. Wir bräuchten da aus jetziger Sicht, bevor wir angefangen haben, vielleicht schon drei Monate länger. Oder wir ändern am Scope was. Wir reduzieren was, wir nehmen was raus oder machen etwas Optional und gucken mal, wenn wir den Zieltermin erreichen, ob wir das Optionale runterbringen oder nicht. Entweder akzeptiert der Kunde das und sagt: „Okay, danke. Wir verlängern den Plan, wir verkürzen den Scope, was auch immer, oder eben nicht. Wenn er sich für das zweite entscheidet, dann steigen wir in das Projekt ein. Und wenn wir uns diesem Zieltermin nähern und sehen, wo wir tatsächlich stehen, habe ich aber auch ein ganz gutes Argument, zu sagen: „Das habe ich vor einem Jahr schon gesagt, dass es genau das und das nicht nicht drin sein kann. Und dann habe ich halt ein ganz gutes Argument, dann die Verlängerung zu kriegen. Das haben wir ja ganz oft mit diesem, wir nennen das immer „Planning Fallacy. Da gibt es ja richtig diesen Begriff, immer im Best Case zu argumentieren und dann hinten raus immer „Sales war richtig gut, aber dann im realen Leben das umzusetzen, ist immer was anderes. Das bringt mich vielleicht noch zu einem anderen Punkt. Du hattest das mal im Vorgespräch erwähnt, wie du mit Fachseiten umgehen kannst, die ja alle auf ihren wichtigen Requirements jeder für sich selbst … Du machst ja sehr viel Anforderungsmanagement, wie du damit umgehst. Das ist richtig, genau. Man bekommt als Anforderungsmanager unglaublich viele Anforderungen, kleine, große, wichtige, persönlich wichtige. Persönlich. Das ist auch wieder das Kennenlernen der Leute. Ist das jetzt ein Feature, das wirklich das Unternehmen weiterbringt in irgendeiner Form oder ist das, was einer nur haben will, was Schön ist? Und ich habe für gewöhnlich nur ein begrenztes Budget für zum Beispiel ein Quartal, was ich da unterbringen kann, und dann fallen halt bestimmte Requirements raus. Und derjenige, der das haben wollte, der ist natürlich dann enttäuscht. Je nachdem, wie sehr der sich jetzt anstellt, gehe ich auch gerne hin und lade dann zweifach Seiten ein und sage: „Ihr habt hier konkurrierende Anforderungen. Der Kollege braucht das und das aus den Gründen und er braucht was anderes. Das hilft oft schon, wenn man einfach mal sich gegenüber übersetzt, menschlich, so wie wir zwei jetzt hier, dass man Verständnis für den Kollegen aufbringt und sagt: „Na gut, ich verstehe, warum mein Requirement ein Quartal später kommt. Und wenn es nicht so ist, der sagt: „Ich will aber unbedingt. Ich bin genauso wichtig, dann kann man vielleicht auch einen Deal machen und sagen: „Gut, du kommst jetzt nicht dran. Dafür bist du ganz weit vorne bis dem nächsten Quartal. Dafür kriegst du dann was anderes. Aber es geht natürlich nur miteinander. Da geht es ums Menschliche. Also zusammenkommen die Leute, also nicht nur über E-Mail, sondern tatsächlich in einen Raum setzen. Das hilft oft. Okay, und wenn wir dann mal zum Thema Menschlichkeit übergehen. Jetzt haben wir so riesen Projekte – du kennst das ja auch – 100, 200 Menschen involviert, meistens dann auch ein großer Teil externe, weil die intern das gar nicht auffangen können, den Umfang der Arbeit. Da ist Menschlichkeit jetzt nicht unbedingt das Top-Thema. Wie bringst du das Thema Menschlichkeit in solche großen Projekte rein aus deiner Sicht? Für mich ist es das Wichtigste tatsächlich. Natürlich müssen wir unsere Tools bedienen, müssen Pläne machen, Kosten bewerten, Risiken und so weiter, Aufgabenpakete schnüren, aber schlussendlich wird es durchgeführt von Menschen. Und wenn ich den Menschen nicht gewinne und der nur Dienst nach Vorschrift macht, dann bekomme ich auch immer ein mittelprächtiges Ergebnis. Und an vielen Stellen ist es auch so, dass ich darauf angewiesen bin, dass mich ein Experte auf etwas aufmerksam macht, auf das ich selber gar nicht gekommen bin, auf eine Lücke, auf ein Problem, das da entsteht oder da irgendwo in der Ecke liegt. Im besten Fall bist du ja dafür da. Ja, aber ich lebe dann tatsächlich von diesem Netzwerk, das ich aufbaue. Das kostet viel Zeit. Also gleich am Anfang des Projektes. Ich beginne am Tag eins, die Leute versuchen, kennen zu lernen, auch ein bisschen privat zu quatschen, herauszufinden, was für ein Mensch das eigentlich ist, mit dem ich da zu tun habe. Und dann kriegt man auch viel einfacher Hilfe, wenn es mal nötig ist. Oder dass jemand was für einen erledigt, der eigentlich gar nicht zuständig ist für diesen Job. Ja, das hattest du im Vorgespräch auch schon mal gesagt, dass du aus deiner Erfahrung, so aus deinen Telco-und Versicherungsprojekten, da oftmals auch gar nicht denjenigen für die Zuständigkeit genommen hast, sondern der, der das macht. Ja, einmal. Man fragt: Wer ist zuständig? Wen frage ich dazu? Dann merkt man, dieser Mensch ist nicht besonders willig, zu helfen, aber durch die Gespräche, die ich vielleicht mit jemand anders hatte, weiß ich, der der kann das auch. Der kann mir auch die Datei liefern oder mir den Report mal schicken oder generieren. Und so komme ich schneller weiter als einer, der nach Schema F arbeitet. Also die Investition in das Menschliche halte ich für eine sehr gute. Unterm Strich bin ich, glaube ich, schneller. Du hattest ja auch mal gesprochen von einem Projekt, wo die Einführung anders geplant war vom zeitlichen Rahmen und du aber dann sozusagen, wenn Ehrlichkeit und Menschlichkeit schon mal kombiniert, wie man da die Kuh vom Eis kriegt. Das war ein größeres Projekt bei einem Versicherungskunden. Da ging es die Einführung einer nagelneuen Software. Die Software selber befand sich noch im Beta Stand. Deswegen hatte auch der Hersteller Mitarbeiter vor Ort geschickt. Dummerweise waren die Mitarbeiter auch nicht so erfahren. Und dann war schnell die gesamte Projektlaufzeit vorbei, das Budget ausgegeben und die Software funktionierte vorne und hinten nicht. Dann mussten wir diesen Gang nach Canossa machen und haben mit dem Auftraggeber gesprochen, haben ihm die Situation erklärt. Er hat dann einmal tief Luft geholt und uns dann gefragt: Wie kann es weitergehen? Wir hatten uns vorbereitet darauf, hatten neuen Plan erarbeitet, neues Budget, ein bisschen Personalveränderungen. Nachdem er dann geschluckt hat, hat er aber das Ganze beim Vorstand durchgebracht. Wir haben das direkt zu Ende gebracht, es funktionierte und selbst Jahre hinterher haben sich die Mitarbeiter, die das wirklich benutzt haben, dieses Softwarepaket, noch bedankt. Das ist so super. Es hat sich echt gelohnt, da noch mal extra Zeit und Geld reinzustecken. Aber Du bist sozusagen bei dem Gang nach Canosa, hast du die Kraten auf den Tisch gelegt? Ja. Und wie viel mehr Zeit hattest du dann gebeten? 100%. 100% mehr Zeit? Ja. Okay. Das war mit einem Jahr angesetzt und schlussendlich haben wir zwei Jahre gebraucht. Aber habt es dann trotzdem noch erfolgreich durchgeführt? Dann war es erfolgreich, ja. Und wenn wir auf den dritten Punkt mal eingehen, das Thema Fragen, Fragen, Fragen, Fragen, dann habe ich immer so die Wahrnehmung, dass da viel Angst besteht, Fragen zu fragen, weil man dann vielleicht nicht so rüberkommt, dass derjenige, wofür man ja eingekauft wurde, der sollte eigentlich die Antworten mitbringen. Du hast aber sehr gute Erfahrungen damit gesammelt, mehr zu fragen als gewöhnlich, damit dann besser zum Erfolg zu kommen. Mehr als nötig, genau. Mehr als nötig, ja. Man kann vielleicht sagen, ich kann diese zehn Fragen fragen, wenn ich die Antworten habe, dann kann ich daraufhin ein Ergebnis planen und jetzt reichen. Das habe ich vor langer Zeit mal gemacht, in einem Telekom-Projekt, und das führte dazu, dass die Software perfekt produktiv war und die Fachseite gesagt hat: „Das wollten wir aber gar nicht haben. Wir wollten was ganz anderes. Also komplett an der Fachseite vorbei? Komplett an den Anwendern. Wir haben Fachseitenvertreter gehabt, aber nicht die eigentlichen Anwender, die täglich damit arbeiten. Und die, die das dann bekommen haben, die haben gesagt: „Damit können wir nichts anfangen. Also es lief technisch in In time and budget, wie man so schön sagt, aber vollkommen sinnfrei. Deswegen investiere ich lieber mehr Fragen vorneweg und kläre: „Was wollt ihr? Warum wollt ihr das denn haben? Oft noch ist die Motivation, nach einem Feature zu fragen, eine ganz andere, als man sich das so vorstellt. Vielleicht aus irgendeiner Sorge heraus, aus einer Angst heraus oder aus einer falschen Vorstellung, was dem Anwender das überhaupt bringt, wenn er dieses Feature bekommt. Deswegen frage ich lieber länger. Wir hatten da auch über das eine Beispiel gesprochen, eine uralte Software abzulösen, die 30 Jahre beim Kunden im Einsatz war. Dementsprechend auch die Fachseiten 30 Jahre teilweise, wenn Sie dieses Tool benutzt haben. Sehr gewöhnt daran dieses Tool benutzt haben. Das sah aus wie Windows 3. 1, für die, die das noch kennen. Und dann musste was Neues her und die neue Technologie war eine Web-App. Also was komplett anderes. Was komplett anderes. Andere Oberfläche, anderer Bedienkonzept und auch die Entwickler auf der anderen Seite. Das waren alles Leute frisch von der Uni, die kannten natürlich auch nur diese aktuellen, sprich modernen Technologien. Und das sind zwei Welten, die da aufeinander geprallt sind, die sich gegenseitig nicht verstanden haben. Da seid ihr auf eine Tür und Ja, eher geschlossene. Ja, das waren auch viele, viele Runden und da die Fachseite auch einfach zugemacht hat und gesagt hat: „Wir wollen das nicht. Geh weg. Da sind wir dann dazu übergegangen und haben Mock-ups gemacht. Wir bauen etwas, das so aussieht wie die Anwendung, ohne die ganze Funktionalität dahinter und zeigen denen das. Und damit haben wir sie dann wieder zurückgekriegt. Dadurch konnten die dann auch die da aktiv mit uns reden und sagen: „Okay, dann klickt doch mal hierhin. Was ist denn, wenn ich jetzt diesen Fall habe? Wie würde ich denn damit umgehen? Wir haben diesen Mockup auch ein paar Mal geändert. Der hat auch Zeit und Geld gekostet. Das muss ich natürlich auch mit dem Auftraggeber abstimmen. Er hat auch da so ein bisschen geschluckt und gesagt: „Eigentlich ist die Analysezeit vorbei. Die Lösung, wenn wir die so bauen, ich glaube, das wird nicht gut ankommen. Lass uns lieber noch ein bisschen weiter analysieren. Und wie hast du es geschafft, diese Brücke zu schlagen zwischen diesen jungen Entwicklern und den wahrscheinlich, also entnehme ich jetzt deiner Bezeichnung, den eher älteren Kandidaten, die das dann nutzen, den erfahrenen, die das dann nutzen, weil das war ja bestimmt auch ein großer Graben jetzt einfach erst mal. Ja, da kommt wieder dieses Netzwerkaufbau und ich habe halt mit den Entwicklern auch viel gesprochen und habe antwortet: „Was könnt ihr denn anbieten? Was könnten wir denn machen? Wie könnte das möglichst angenehm für den Anwender sein, dass der sich nicht so großartig umgewöhnen muss? Und von allem der jungen Entwickler kam dieser Vorschlag: „Dann lasst uns doch mock-up machen, bevor wir das jedes Mal bauen, testen, live setzen und dann sehen, ob das passt. Machen wir nur so eine Pseudo-Oberfläche. Dadurch habe ich die gewonnen und dadurch, dass ich den Fachseiten nicht eine Powerpoint-Präsentation nach der anderen die Ohren gehauen habe, sondern gesagt habe: „Ich zeige euch mal, wie das aussehen kann. Ich starte mal einen Browser. Aber das halbpannfest ist … Ehrlich gesagt, da passiert nichts hinter. Wenn ich jetzt auf „Speichern klickt, da wird nichts gespeichert. Aber das ist so die Handhabe. So würdet ihr so so einen Businessprozess durchführen und dann konnten die sagen: „Okay, das ist schon mal ganz gut, aber da hinten hätten wir gerne noch das und das. Na gut, dann bauen wir so einen Pseudobutton da mal rein und dann zeigen wir dir, wie das aussieht, was für eine Liste du sehen kannst, die natürlich dann hart codiert mit den Daten war. Da war nichts hinter an der Datenbank. Aber dadurch konnten die ein Gefühl gekriegt: „So könnte das aussehen. „ja, wenn das so aussieht, damit können wir leben. Und dann war die Akzeptanz da, bevor wir es überhaupt gebaut hatten. Also wie das jetzt immer so schön benannt wird, Change Management. Am Ende, Menschen reden mit Menschen und finden Lösungen. Also wenn ich es mal zusammenfassen darf: Ehrlichkeit, Menschlichkeit und das Thema immer wieder zu hinterfragen oder Fragen zu stellen, damit man gar nicht erst zu lang in eine falsche Richtung läuft, sondern alle mitnimmt. Das sind tolle Beispiele. Wenn jetzt eins von denen fehlt, von den Elementen, aus deiner Sicht, oder was würdest du sagen, ist so die Quintessenz für dich, wenn du die drei Themen betrachtest? Wenn ich zusammendampfen muss, hat der Herr machen gesagt, es gibt Tools und Methoden, die sind wichtig, aber nicht alleine erfolgsführend. Für mich ist es der menschliche Faktor: Menschen sind nun mal keine Maschinen. Eins und eins ist nicht immer eins. Man muss auch immer fünfe gerade sein lassen. Und wenn man dem entgegenkommt, zeigt, wenn man Verständnis zeigt für die Bedürfnisse, die oft genug auch verborgen sind, nicht jeder Er sagt sofort, warum er was will. Ich will das jetzt so haben. Du bist der Externe, du baust das jetzt nämlich so. Ich frage dann, warum. Nicht immer, aber oft genug kann man das herausfinden und dann erklären: Klar, können wir das bauen? Kostet unglaublich viel Zeit und Geld, aber das erfüllt nicht dein echtes Problem. Nachdem ich jetzt weiß, was du eigentlich willst, wie wäre es, wenn wir das machen? Ja, das sind ja auch meistens die Leute, die am meisten dann auf diese Ebene sich begeben sind, sind am längsten in den Projekten. Wenn du jetzt so einen praktischen Tipp mitgeben müsstest, wir heißen ja Smart Hacks, aber das sind heute keine technischen Hacks, sondern eher was Zwischenmenschliches. Was wäre da so dein Tipp, wenn man morgen damit starten möchte? Vollkommen analog. Geht mit eurem Kunden einen Kaffee trinken und lernt den Menschen kennen, der da gegenübersitzt. Nehmt euch die Zeit. Investiert die Zeit, weil die kommt mit Dividenden zurück. Und alle, die jetzt auch diese Zeit investiert haben für unseren Podcast, vielen Dank fürs Zuhören. Wer gerne mit Andreas Kontakt aufnehmen möchte, ihr habt bei uns in den Shownotes natürlich noch alle Kontaktdaten. Ich kann euch nur empfehlen, mit Andreas in Kontakt zu treten. Auf jeden Fall wäre es ein Mehrwert für euer Projekt und abonniert gerne unseren Kanal. Und ansonsten bedanke ich mich für das Gespräch, Andreas. Sehr gerne. Und wünsche allen hören noch einen guten Tag, eine gute Fahrt, was auch immer ihr gerade macht. Bis dann. Ciao.