Stichworte: Ergebnis denken, unerwartete Probleme vermeiden, Betriebsphase, Feedback der Kunden, Herausforderungen, Kommunikation, Veränderung

In dieser Folge sprechen wir über das Thema „Vom Ergebnis her denken“ und wie man unerwartete Probleme in Projekten vermeiden kann. Wir betonen die Bedeutung, auch in der Betriebsphase eines Projekts weiterzudenken und Feedback der Kunden einzubeziehen. Außerdem diskutieren wir über Herausforderungen in der Kommunikation und Veränderung von Unternehmen.

Transcript

Mel:
[0:00] Moin Fabian. 

Jubiläumsfolge – Management by Projects, Ausgabe Nummer 20

Fabian:
[0:01] Salü Melvin. 

Mel:
[0:02] Management by Projects, Ausgabe Nummer 20. Yay, kleines Jubiläum. 
Wir sind total happy, haben hier eine Flasche Sekt auf dem Tisch stehen und freuen uns, eine neue Folge aufzunehmen. 
Und quasi passend zu der Flasche Sekt, die hier virtuell auf dem Tisch steht, möchten wir heute über das Thema sprechen. Vom Ergebnis her denken. 
Gemeint ist damit, dass wenn man Projekte startet, hat man ja ganz oft ein gewisses Lösungsdesign oder man startet mit so einer Analysephase und überlegt sich, hey, was müssen wir jetzt machen und so weiter. 
Und dann kommt man so in das Hamsterrad an, man baut einen MVP, man fängt an, die Lösung umzusetzen und so weiter. Und auf einmal steht man dann kurz vor der Einführung und dann kommt es richtig dicke. 
Dann kommen quasi die Betriebsorganisationen und sagt so, ja, wo ist denn jetzt das Montagehandbuch? 
Und dann kommt irgendjemand und sagt so, ja, jetzt müssten vielleicht noch die Anwender geschult werden. 
Und dann kommt jemand, der sagt irgendwie noch, naja, Logistik, so Lager überhaupt nicht vorbereitet, keine Produktnummer im System und so weiter. 
Und das ist natürlich eine Vollkatastrophe, die dann ein eigentlich gut geführtes Projekt auf den letzten Metern nochmal ganz schön den Schlitt anbringen kann. 
Und deshalb möchten wir heute diese Folge genau diesem Thema widmen, wie man ja vom Ergebnis her denkt und was wirklich wichtig ist, um auch auf den letzten Metern Projekte dann erfolgreich ins Ziel zu bekommen. 
Und wie immer würde ich dann einfach nach der Anmoderation an dich übergeben, Welche Erfahrungen hast du da gemacht? 

Fabian:
[1:27] Ich habe gerade einen konkreten Anlass, wieso das mich auch gerade nochmal zusätzlich beschäftigt, weil ich habe im Zusammenhang mit den Projekten, die Melvin und ich verantworten, Darf ich gerade Interviews machen mit relativ erfahrenen Leuten in unserer Organisation? 
Da gibt es drei sehr prominente Projekte, die mir gerade in dem Zusammenhang genannt wurden, die ich explizit nicht benennen möchte. 
Einfach am Flughafen in Berlin zu tun vermutlich. 

Mel:
[2:03] Zum Beispiel. 

Erfahrung mit eigenen Verbrechen oder Vergehen

Fabian:
[2:05] Oder wo du einfach staunst. Einerseits kenne ich das aus eigener Erfahrung, sicher auch schon selber mit Verbrochen oder Verbrochen. 
Ich habe auch schon erwähnt, es war nicht ein riesen Software-Projekt, aber eines meiner ersten Projekte als Junior in der grösseren Organisation, wo wir jetzt unterwegs sind, war ein Software-Projekt. 
Und auch da muss ich sagen, habe ich sozusagen den Betrieb, die effektive Nutzung dieser Software an den Betrieb zu wenig gewichten können. 
Und ich habe einfach drei Beispiele von richtig grossen Projekten wieder gehört. 

Die Thematik des Crewwechsels in der Betriebsphase

[2:45] Es ist auch eine Hand-over-Thematik. Oft hast du ja dann in der Betriebsphase effektiv nicht mehr die gleiche Crew, das hast du auch schon gesagt, oder? 
Aber dann manchmal auch eine Verhältnismässigkeitproblematik, oder? 
Ich meine Leute, die Entwicklungsprojekte machen, sind so Fan. 
Yeah, hippie, was Neues entwickeln, da fühlt man sich richtig cool, oder? 
Aber es ist ja auch einer der absoluten Klassiker. Welches Problem löse ich wirklich und wer ist wirklich mein Kunde, gehört ja irgendwie auch dazu. 
Und ich habe einfach gestaunt, wenn du dann die Geschichte hörst. 
Das steht halt nicht in den offiziellen Projektberichten oder das, was in Mensch steht. 
Wir haben einfach seit Jahren Millionen Herausforderungen, weil diese Betriebsphase im Handel und, danach nicht wirklich mitgedacht wurde oder konnte. 
Es ist kein Fingerpointing-Thema. Es ist einfach wirklich eine strukturelle Herausforderung, das zu tun, weil manchmal ist es schon schwer genug, überhaupt das Ding zu bauen, entwickeln oder was auch immer. 

Projekte und Ambitionen in Industrie und Software

[3:54] Ich denke, es ist ein Klassiker eher für Industrieprojekte oder Softwareprojekte und so weiter. 
Jetzt nicht unbedingt marketingorientierte Geschichten, Da merkst du relativ schnell, wenn es der Kunde dann nicht kauft, hört es dann wieder auf. Hast du da auch so… 
Für mich ist es eines der Themen und eines der Ambitionen, immer wieder da wirklich besser zu werden. 

Mel:
[4:19] Ich bin extrem dankbar, dass du nicht gesagt hast, dass es die Königsdisziplin ist. 

Fabian:
[4:24] Es ist immer das Thema in jeder Folge. 

Mel:
[4:28] Ich habe mir schon hier so einen kleinen Jingle zurechtgelegt, in den zukünftigen Folgen wird es immer, wenn einer von uns das sagen, wird es dann ein Katsching geben und können dann am Ende der Folge sagen, an wen wir hier eine Spende machen. 
Nein, was mir dazu einfällt ist, oder was ich beobachtet habe in verschiedenen Projekten, diese ganzen betrieblichen Anforderungen, die stehen in der Regel auf keiner Anforderungsliste. 
Kommen immer hinten runter, sondern du hast immer ein Projektziel, das heißt dann irgendwie Kosteneinsparung oder keine Ahnung was, aber quasi stabiler Betrieb ist nie eine Anforderung, die explizit da nochmal genannt wird. Das ist so das eine. 
Das andere, und das hast du eben schon angerissen, und die Erfahrung habe ich echt leidlich auch gemacht, ist du baust dann eine Projektorganisation auf und sagst denen irgendwie, ihr müsst hier machen und tun und Innovation und sowieso und überhaupt und dann fangen die quasi an im eigenen Saft sich zu überlegen, was jetzt die Lösung ist. 
Und ganz oft hat man ja, weil man in diese Projektteams ja dann irgendwelche sogenannten Experten reinsteckt, die Situation geschaffen, die meinen dann tatsächlich, es auch noch besser zu wissen und meinen das auch gar nicht böse, aber die fangen dann tatsächlich an, die Welt neu zu erfinden. 

[5:43] Und definieren sich dann quasi selbst, also es ist so eine Form von Selbstermächtigung, wo die dann anfangen quasi sich selbst Anforderungen zu generieren oder das wäre jetzt auch noch cool und das wäre auch irgendwie jetzt noch praktisch zu haben und daraus entstehen dann so Projekte, die riesengroß sind und nie über die Konzeptphase hinauskommen, weil jemand sagt, jetzt bräuchten wir noch das und jetzt wäre das noch total cool das zu haben und wenn wir das noch hätten, dann könnten wir die und die Geschichte auch noch machen, ohne dass es alleine einen Stakeholder gibt, der das haben will. 
Und ohne, dass das halt nachher irgendwann mal wirklich in den Betrieb ankommt oder das mal auch regelmäßig geschaut wird, ist das überhaupt betreibbar, dieses System. 
Und von daher finde ich das jetzt auch in dem eben schon angesprochenen Projekt von uns ganz spannend eigentlich wirklich zu sagen, wir machen jetzt mal eine ganz trockene, ganz schulbuchmäßige Interview-Session mit den Stakeholdern. 

Externe Lösungsstruktur ohne Dienstleistung

[6:38] Und lassen uns danach ganz bewusst extern mal die dazu passende Lösungsstruktur bauen und zwar nicht in Form einer Dienstleistung, also nicht im Sinne von wir holen uns dann Leute rein, die das hier irgendwie bei uns machen, sondern komplett autark, macht quasi mal nur die Extraktion von dem, was die Stakeholder jetzt gesagt haben und es spricht ja überhaupt nichts dagegen danach dann hinzugehen und zu sagen, so jetzt steigen wir in die Optimierung ein, also das ist quasi das, was ihr uns in die Finger diktiert habt und das ist wahrscheinlich an der und der Stelle viel heute und dann hat das bestimmt noch viel Optimierungspotenzial oder Dinge, die einfach unklar sind. 
Aber erstmal wirklich zu sagen, dass das Grundsystem, das Basissystem, das rein aus den Anforderungen der Stakeholder gespießen ist, wie sieht das aus und danach überlege ich mir irgendwie, was ich mir noch Tolles drumherum bauen kann, was irgendwie noch hip und technisch möglich und Blockchain, Bitcoin, was weiß ich was wäre. 

[7:33] Das kann ich ja dann nachträglich noch machen. Andersrum, die angenehmsten Projekte, die ich bisher gemacht habe, waren immer die, die einen direkten Betriebsimpact hatten. 
Also wenn, ich hatte mal die Ehre in einem Corporate Startup Ende zu Ende inklusive Betriebsorganisation 24-7, 365 Tage im Jahr verantwortlich zu sein. 
Und das macht dann natürlich total viel Spaß, weil da hast du A, den Business Case direkt bei dir, du weißt irgendwie, der Kunde ist bereit X zu zahlen pro überwachter Einheit. 

Direkter Betriebsimpact für effektive Projekte

[8:03] Und dann fängst du da tatsächlich an, dir zu überlegen, hey, wie muss jetzt erstmal mein Prozess aussehen, dass ich in den 24 7 Service überhaupt personaltechnisch, bekomme, dann fängst du an dich selbst zu optimieren und fragst, wie kriege ich das ich 24-7 mit möglichst wenig Personal hinbekomme und trotzdem hast du in der Regel eine Service Agreement, wo dann drin steht, naja und die Ausfall darf nicht länger sein als so und du musst reagieren in Zeitablauf und sowieso und überhaupt und da kommst du dann sehr stark vom Betrieb her und da hast du dann aber auch relativ einfaches Spiel gegenüber der Entwicklungsabteilung, weil du halt tatsächlich einfach sagen kannst, so Freunde, mehr als den Betrag x bekomme ich für diese Leistung nicht und wir müssen bestimmte Reaktionszeiten sicherstellen bzw. 
Ihr müsst das technisch sicherstellen und dem hat sich alles unterzuordnen und diese diese klaren nicht funktionalen Anforderungen das ist ja in der Regel das, wo es dich nachher im Betrieb dann killt, wenn die nicht glatt sind. 

Fabian:
[8:59] Es ist genau so, weil es ist genau auch das denke ich, wo der Ansatzpunkt dann ist. 
Es gibt es dann ja konzeptionell, wie du überlegen kannst, Wie kann ich das besser machen? Das andere ist dann, wie mache ich es faktisch so, dass es wirklich geschieht? Und ich glaube, du brauchst Dinge nie. 
Also du brauchst schlussendlich Personen, die dich einfach immer wieder daran erinnern, oder? 
Weil das Problem ist ja, dass du dem wie auch ausweichen kannst. 
Also nur dann passiert es ja, weil wenn du das wie eine Wand spürst, da ist ein Kunde oder da ist ein Abnehmer und der sagt mir genau, wo er dann mitgeht und was er gut findet und was nicht. 

Mel:
[9:46] Und zeitnah. Zeitnahes Feedback. 

Fabian:
[9:48] Und das heisst ja gar nicht, dass dann immer alles wahr sein muss, was der sagt. 
Aber ich glaube, du musst sicherstellen, dass du dauernd eine Erinnerung hast und dauernd ein intellektueller Prozess ausgelöst wird in deinem Projekt oder bei den Projektmitarbeitern und dir selbst, dass du dich mit diesen Fragen auseinandersetzt. Ich glaube, es ist eine Aufmerksamkeitsproblematik. 
Du musst ihnen dem genug Aufmerksamkeit frühzeitig schenken müssen. 
Das wäre so eine These, wie man das vielleicht angehen kann. 
Weil sonst sind ja große etablierte Organisationen sind ja genau immer noch, auch wenn man da dauernd versucht, das zu ändern, so aufgebaut, dass das eine Ende das andere Ende nicht so richtig spüren muss, oder? 
Das ist einfach, ich glaube, ein grösseres Problem. 
Ich glaube, es ist schwierig, das mit anderen Organisationsformen wirklich zu lösen. 
Ich glaube, es ist einfach eine Grösse. 
Also, wenn du zehn Leute hast, die eine Wertschöpfungskette verantworten, dann kann es jeder noch den anderen verstehen. Und wenn du 100 hast, dann darfst du sowieso, und wenn du 1.000 hast, sowieso nicht mehr. 
Das ist einfach dann nicht mehr möglich. und dann, ich glaube, du… 

[11:02] Ich glaube, du kommst da nie ganz raus. Man kann sicher besser sein als Organisation oder schlechter, aber so ganz raus kommst du aufs Thema nie, dass du den Kunden nicht spüren musst, wenn du nicht das bewusst tust. 
Oder das Endprodukt oder die Übergabe an die Linie oder was auch immer es dann ist. 

Mel:
[11:22] Ich glaube, es ist so ein bisschen dieses Thema, wenn du Chainspücher liest, dann ist ja quasi auch das, was auf der Seite einsteht, irgendwie ein Gefühl von Dringlichkeit erzeugen. 
Und ich glaube, daran scheitert es, weil wenn du ein Entwicklungsprojekt hast, dann ist die einzige Dringlichkeit, die da ja entsteht, dass irgendwann das Geld alle ist und bis dahin muss es quasi fertig sein. 
Und das ist aus meiner Sicht die Begründung auch dafür, warum du in Entwicklungsprojekten dazu neigst, Dinge umzusetzen, die dir später im Betrieb richtig auf die Füße fallen werden, weil du halt einfach fertig werden musst, weil irgendwie Geld knapp wird oder keine Ahnung. 
Und weil es aus deiner Projektsicht halt egal ist, ob das, was du da gemacht hast, jetzt quasi jedes Jahr im Betrieb Millionen Kosten verursacht oder nicht, weil es ist ja nicht dein Geld. 
Und gleichzeitig, wenn du ein System dann quasi mal in Betrieb genommen hast und egal wie buggy das ist, es produziert ja Einnahmen. 

[12:17] Und ich kenne das nicht, dass Unternehmen auch irgendwie mal gezielt hingehen würden und quasi sagen, keine Ahnung, wenn wir diese drei Bugs in unserem System fixen würden, dann könnten wir 20 Prozent der Belegschaft einsparen oder sowas. 
Also es ist mir quasi nicht bekannt, dass sowas strukturiert gemacht werden würde oder ich habe es zumindest noch nie gesehen. 
Gesehen. Aber genau das ist es ja. Das System läuft dann irgendwie und es wird letzten Endes auf dem Rücken der Mitarbeitenden, die dann damit umgehen müssen, wird das gefixt, weil die machen das quasi mit Blutschweiß und Tränen im operativen Geschäft. 
Aber als Unternehmen bezahlst du es in Form der Gehälter von den Leuten, wo man wahrscheinlich nicht relativ einfach in einem Business Case rechnen würde im Sinne von mach folgende Improvements, folgende Updates, dann kannst du dir irgendwie 3, 4, 5 x Leute sparen, die heute einfach nur den manuellen Workaround darstellen. 

Fabian:
[13:06] Bei Total Cost of Ownership schlägt die Betriebsphase in der Regel immer die Entwicklungsphase. 
Es gibt Beispiele, wo es nicht so ist, wenn du eine Rakete baust, aber relativ schnell, wenn du ein einigermaßen Objekt hast oder ein System, das einigermaßen eine Lebenszeit hat, wird die Betriebsphase in der Regel dann dominieren. 
Das Absurde ist ja, es gibt niemanden, der das direkt spürt. 

Mel:
[13:34] Und der das Controlling dafür kann. Also nimm eine beliebige Anwendung heute und erklär mir mal, was die operativen Kosten sind. Weil das ist ja dann alles auch geshared und sonst was. 

SAP-Projekte und Probleme in der Betriebsorganisation

Fabian:
[13:44] Du kannst einen Klassiker nehmen, der ja, ich glaube weltweit, SAP geht in die Cloud und jetzt, ist ja 20 Jahre später als andere, passiert und jetzt machen alle neue SAP oder und, Ich bin sicher, in jeder zweiten Unternehmung wird es massive Probleme geben im Handhauen zur Betriebsorganisation. 
Das ist ja die normale Organisation in dem Fall. 
Wahrscheinlich gibt es das bei jedem SAP-Projekt. 

Mel:
[14:22] Und was ich meinte, war sowas wie, keine Ahnung, stell dir ein Callcenter vor, das betreut irgendwie fünf Anwendungen oder sowas und jetzt sag mir aber mal, was die Betriebskosten von einer dieser Anwendungen sind. 
Es ist ja alles irgendwie Shared Service und geteilt und Gemeinkostenverteiler und Umlage und sowieso und überhaupt, also kriegst du die Betriebskosten eigentlich raus oder versackt das einfach im großen Schlund deiner Betriebsaufwände? 
Das kontrolliert ja auf der Ebene keiner und das macht es ja für Projekte so angenehm, Einfach zu sagen, naja, ist dann halt irgendwie im Betrieb nicht so geil, wie es hätte sein sollen. 

Fabian:
[14:53] Ist halt so. Ich finde solche Problemstellungen immer recht faszinierend, weil ich würde mal sagen, alle Leute mit Erfahrung wissen das, oder? 
Gleichzeitig gibt es die meisten Leute. Mölwin hat mich gerade sehr kritisch angeschaut. Viele Leute, viele, viele. 

Mel:
[15:12] Ich habe überlegt, alle Leute, die schon mal im Betrieb gearbeitet haben. 

Fabian:
[15:17] Einige Leute wissen das, aber es sind immer noch genug, die die Podcasts machen. 

Mel:
[15:22] Ja, vielleicht. 

Schwierigkeiten und Belohnungen der Prozessoptimierung

Fabian:
[15:24] Und es ist schon faszinierend, ich glaube es ist auch einfach Schwierigkeit, das hast du auch schon erörtert, das haben wir auch schon gerade ausgeführt, aber gleichzeitig auch extrem lohnend. 
Also ich bin jemand, ich glaube daran, dass es sich auszahlt, also für eine Organisation sowieso, aber ich glaube auch als Individuum, wenn du versuchst, solche Dinge besser zu machen. 
Also weil, ja, dann heisst es ja, Person X hat dieses Projekt gemacht und danach war einfach alles scheisse. 
Um es ein bisschen plump zu formulieren, das geht ja nicht ganz spurlos an einem vorbei, oder? 
Also das erst mal, ja, und da, das fasziniert mich doch, dass es, dass dieser Anreiz scheint nicht ganz so einzuzahlen, wie, ja, wie vielleicht notwendig, ja. 

Mel:
[16:15] Ich glaube tatsächlich, dass das auch ein Stück weit unterschätzt wird, also gerade wenn du so an so Themen denkst wie zum Beispiel Schulung. 
Mir hat neulich ein Kollege erzählt, die haben… 
Technologie eingeführt und dann mussten sie da irgendwie eine zweistellige Personenanzahl schulen und das hat zwei Wochen gedauert und jetzt stell dir mal vor du bist eine Flächenorganisation und die drittgrößte Hörerschaft dieses Podcast kommt ja erstaunlicherweise aus den USA, Grüße an der Stelle, wer auch immer das ist. 
Stell dir mal vor du bist Flächendienstleister in den USA und du hast keine Ahnung, 1000 Leute im Field Service, 10.000 Leute im Field Service, du musst jeden von denen 2 Wochen rausnehmen und auf irgendwas Neues schulen. 

[16:58] Was das A für Aufwände sind und was das halt auch für einen Zeitbedarf braucht. 

[17:02] Und ich glaube es ist einfach auch da total unterschätzt, weil du entwickelst so vor dich hin und dann hast du irgendwie Alpha-Release, dann hast du Beta-Release und dann sagst du so jetzt werden wir langsam soweit. 
Und dann können wir ja jetzt mal anfangen uns über Schulung Gedanken zu machen und ich behaupte das ist zu spät. 

[17:17] Du musst dir von Anfang an und das ist aus meinem Verständnis ehrlich gesagt auch Teil der UX, also der User Experience, sich zu überlegen wie schule ich eigentlich nachher die Anwender davon, wie sieht mein Bildungskonzept aus, schule ich die on block, mache ich da irgendwie blended learning noch mit irgendwie on the job und remote und self learning und was weiß ich was es da alles für Konzepte gibt, Um wirklich frühzeitig hingehen zu können, um solche Situationen, wie eben beschrieben, die dann richtig auch ins Geld gehen und die richtig zeitaufwendig sind, auf dem Schirm zu haben, weil sonst landest du immer beim Klassischen. 
Also dann hast du halt wirklich irgendwie, ich hab fertig entwickelt und dann verzögert sich der Release-Start, weil ich irgendwie nochmal zwei Monate die ersten Leute schulen musste, weil mir außer Train the Trainer nichts clevereres eingefallen ist. 
Eingefallen ist und dann habe ich da irgendwie pro Region irgendwie so einen super User und der arbeitet aber auch nicht, weil er die ganze Zeit damit beschäftigt ist, den anderen Leuten zu erklären, die eben nicht wissen, wie das System funktioniert. 
Und sofort habe ich am Anfang schlechte Presse zu einem Produkt, was wahrscheinlich eigentlich total cool ist. 
Ich habe es nur einfach nicht geschafft, das zu vermitteln und das ist einfach, das ist dann so schade, wenn du da wirklich Projekte hast mit einer entsprechenden Laufzeit und Herzblut und Gedanken, die da reingeflossen sind und dann verboxt du es auf den letzten Wusste. 

Die Bedeutung von Kommunikation und Kundenzentrierung

[18:33] Die eigentlich vorhersehbar gewesen sind, dass du irgendwann den Anwender da irgendwie mitnehmen musst. Und das passiert so oft. 

Fabian:
[18:41] Ja, es ist total faszinierend, weil ich oute mich hier ein bisschen. 
Ich bin so aus der Generation Gaming, oder? Also ich habe dann in den 90er Jahren da mit allen Geschichten mitgemacht und mich fasziniert es total, dass immer noch Down-Spiele rauskommen, die dann total buggy sind und total abstürzen. 
Und ich bin sicher, auch da, die haben alle Agile X, Y, Z usw. 
Eingeführt. Und alle wissen, MVPs und Testen und Kundenorientierung usw. 
Aber es passiert trotzdem immer noch. 
Und es wird auch weiterhin passieren, da bin ich sicher. 
Mich fasziniert, dass die Lernkurve, dass die individuell zu sein scheint. 

Mel:
[19:30] Ja, wobei das ja in Teilen gewollt ist. Also dieses Phänomen der grünen Bananen, dass du tatsächlich ganz bewusst hingehst und sagst, die Anwendung reicht beim Kunden, weil es ist einfacher oder günstiger. 
Der Kunde wird mir schon melden, was alles nicht funktioniert, als wenn ich meine Tester da dran setze. Das kannst du natürlich machen, wenn du irgendwie Microsoft bist oder Apple oder sonst wer. Wenn du Monopolist bist oder quasi Monopolist dass es dir halt egal ist, wenn irgendjemand dann sich doch ein Android oder was weiss ich was kauft. 
Oder du halt durch quasi Vendor-Login gezwungen bist, weiterhin Microsoft Office zu benutzen. 
Dann kannst du solche Spässe ja machen, aber eigentlich ist es aus einer wirklichen kundenzentrierten Denkweise herausgedacht, muss ich sagen, das ist eine Zumutung. 

Fabian:
[20:11] Also vor allem, wenn du das als… Das ist eine Frage der Kommunikation, oder? Also das, ich meine, ein MVP ist ja nichts anderes als solches deklariertes Erstprodukt, oder? Und da gehst du auch also… 
Hast du in der Regel nicht die Möglichkeit, das an Millionen zu verteilen, oder? Da ist der Unterschied. Und sobald du das richtig einordnest und so weiter, ist alles in Ordnung. 
Wenn du natürlich sagst, das ist jetzt das Ding, das ist super und es läuft, dann mich fasziniert, dass das immer wieder geschieht. 

Mel:
[20:42] Ich möchte eine total peinliche Anekdote dazu erzählen und du wirst wahrscheinlich richtig lachen. 
Ich bin einmal in meinem Leben Beta-Tester gewesen. 
Ich war kein offizieller Beta-Tester, sondern das war in den 90er-Jahren. 
Und da hatte ein Bekannter von mir eine Vorab-Version von Windows Vista. 
Und damals war File-Sharing und so was noch total das Thema. 
Und dann haben wir uns darum gestritten, ob wir nicht eine Kopie von Windows Vista bekommen haben, damit wir das vor allen anderen testen können. 
Und es war furchtbar. Und wenn man weiß, dass Windows Vista die schlimmste Windows-Version, die es hier gegeben hat, gewesen ist, ist es rückblickend total lustig. 
Aber gerade weil das so ist, in der Gaming-Industrie wird das ja im großen Stil gemacht mit Alpha- und Beta-Testen und probiert das aus und da hängt ja dann auch richtig Geld dahinter. 
Da werden ja Leute dafür bezahlt, stundenlang zu zocken und sämtliche Bugs, die sie unterwegs finden, irgendwie zu finden. 
Und andersrum ist es ja bei anderen Produkten durchaus auch üblich, dass es da so Bug-Bounties und sowas gibt. 
Also, dass du, wenn du Fehler meldest und die dann tatsächlich auch reproduzierbar sind, dass du durchaus von deinem Systemlieferanten da eine Gutschrift für bekommst. 
Aber ja, nichtsdestotrotz, das ist dann bei kommerziell genutzten Geschichten so. Aber wenn du wirklich so eine interne Applikation oder sowas baust, es ist wirklich eine Elend, diese Betriebsphase. 

Bewusste Kommunikation und Investition in das System

Fabian:
[22:08] Aber das ist, ich glaube, gerade aus dieser Diskussion her lässt sich analytisch noch etwas Interessantes sagen. Ich glaube, wie du schon gesagt hast, du kannst solche Dinge auch sehr bewusst machen, oder? 
Du kannst auch bewusst ein bisschen an die Grenzen gehen, also wie du es auch kommunizierst. 
Und ich denke, das ist eigentlich der Schlüssel, oder? 
Also du kannst bewusst sagen, ich weiss, dieses System hat jetzt drei, vier Jahre Kinderkrankheiten, und dich entsprechend dann auch aufstellen, es so zu begleiten, oder? 
Ja, weil es ist eine Investmentfrage. Zu welchem Zeitpunkt investiere ich wie viel? Ich glaube, die Probleme entstehen insbesondere dann, wenn du das Gefühl gehabt hast, es ist eigentlich auf 90% und es war aber auch 50%, oder? 
Und die Gegenseite auch. Ich glaube, es ist vor allem, würde ich als Zwischenfazit sagen, ist, sagen wir mal, es ist fremd. 
Ja, dieser Punkt, der wohl entscheidend ist. 

Mel:
[23:09] Ja, es ist, glaube ich, wirklich diese Frage der Kommunikation und der Frage, wie gehen wir konkret damit um, auch kommunikativ. 
Also was versprechen wir den Leuten, ist wahrscheinlich auch so ein Teil des Projekt-Marketings dann, ne? 
Also gehst du von vornherein rein und sagst irgendwie, das ist irgendwie die beste Anwendung aller Zeiten, die je gemacht worden ist? Oder gehst du hin und sagst so, naja, wir melden uns ab und zu mal und dann kommt da irgendwas und keiner weiß, was er jetzt da eigentlich gerade serviert bekommen hat. 
Ja, ich glaube, da gibt es dann schon große Schwankungen. 

Menschliche Dimension: Widerstände bei der Einführung des Systems

[23:46] Was noch so ein anderer Aspekt ist, den ich gerne noch kurz diskutieren würde, ist so mehr die menschliche Dimension. 
Also wir haben jetzt viel über quasi technische Aspekte wie Schulung und sowas gesprochen. aber du hast ja auch ganz viel so Situationen, wo du dann die Einführung machst und dann kommen die Widerstände. 
Also dann hast du Leute, die sagen, das will ich aber nicht benutzen oder das alte System war viel besser. 

Widerstände und Bestätigung bei Projekten

[24:10] All diese klassischen Widerstände, die du bei Projekten natürlich sowieso hast und die dich ja auch darin bestätigen, dass es richtig ist, was du getan hast. 
Du hast ja auch immer einen innovativen Charakter in jedem Projekt drin. 
Aber das ist, glaube ich, auch noch ein spannendes Thema, kurz mal zu thematisieren. 
Wie nimmt man auch, gerade wenn es dann in die heiße Phase geht, wie nimmt man da die Leuten mit? 
Da gibt es ja dann so Modelle, die mich ehrlich gesagt alle nicht überzeugen, wie Multiplikatoren-Konzepte und sowas. 
Also, dass du anfängst mit einer kleinen Gruppe und die sollen dann weitererzählen und dann sind das irgendwie so die System-Champions und die müssen das dann irgendwie vertragen. Also du verlagerst im Prinzip dein Problem auf andere Leute. 
Hast du da irgendwas, wo du sagen kannst, da bist du gut mitgefahren? 

Fabian:
[24:56] Woran ich auf jeden Fall glaube, ist, dass du schon in Anfangsphasen … 
Man muss sehr präzise sein. Ich mag immer die stärksten Kritiker. 
Du musst natürlich mit denen gut kommunizieren können. Es darf nicht jemand sein, der sich prinzipiell der Kommunikation verweigert. 
Aber da gibt es auch Sprichwörter dazu. 

Kritische Stimmen als wertvolle Ressource im Risikomanagement

[25:27] Deine Feinde musst du nahe halten. Feind ist da viel zu negatives Wort natürlich, aber ich finde insbesondere gerade so für Risikomanagement Themen und dass du das richtig siehst, ist es extrem gut, sehr kritische Leute nahe einem Projekt zu haben oder viel mit denen zu sprechen. 
Insbesondere auch wenn sie wirklich ein bisschen eine ablehnende Haltung haben, weil dann werden sie sich auch nicht scheuen, dir die Wahrheit zu sagen. 
Das ist etwas, da habe ich wirklich gute Erfahrungen damit gemacht. 
Im Handle-Prozess an sich, muss ich sagen, da habe ich nicht so viele Erfahrungsschätze dazu. 
Ich persönlich habe aber die Einstellung, also du hast wirklich mit tausenden Usern dann zu tun, glaube ich, auch dort, dass du nicht darum herumkommst, doch einen guten Teil an individuellen Menschen wirklich effektiv zu gewinnen. 
Oder wirklich dahin zu gehen und zu schauen, was ist effektiv jetzt die Hürde, was ist effektiv das Problem. 
Da geht es mir ein bisschen wie du, da sind für mich, also diese Change-Konzepte sind als Konzepte sicher nicht falsch. 

Change-Konzepte als möglicher Lösungsansatz

[26:50] Aber schlussendlich ist das wahrscheinlich eine Frage des Momentums. 
Also hast du, findest du die richtigen Leute und kannst du die wirklich überzeugen? 
Das heisst ja auch, dass du etwas für sie tun musst. 
Also du musst denen auch versuchen, so weit du kannst, deinen Schritten entgegen zu gehen. 
Und ich denke, wenn es ein längerer Zeithorizont ist, dann… 
Da musst du dich, da musst du, eben sind so Konzepte nach wieder nicht falsch, weil du musst irgendwo anfangen, oder? 
Und das Problem hast du einfach dann, wenn du da schon nicht in die Gang kommst. 
Ich glaube, das ist zum Teil dann auch bei solchen Softwareprojekten oft der Fall oder auch anderen, wenn das System natürlich effektiv keine Verbesserung bringt. 
Also wenn ein Teil der Skepsis wirklich wahr ist, dann hast du halt schon einen Uphill-Battle, oder? 
Das passiert ja öfters, wie man denkt, weil bestehende Systeme zum Teil 20 Jahre oder 5 Jahre optimiert wurden. 
Wie auch immer, die wurden über einen längeren Zeitraum optimiert und deshalb sind sie an einem relativ guten Punkt. 
Dass dann schon nur mal diese Basisleistung aufzuholen, ist gar nicht ohne. 
Auch wenn du vielleicht technisch ein paar bessere Dinge bietest. 

Mel:
[28:03] Ja, das stimmt natürlich auf der ganz grundsätzlichen Ebene total. 
Was ich aber trotzdem anmerken würde, es macht natürlich einen Unterschied, ob du in einer Big-Bang-Situation bist oder ob du’s schaffst, iterierend vorzugehen. 
Klar, wenn du sagst, hier ist schon mal Version eins und dann kommt Release zwei, drei, vier, fünf und jedes Mal ist es besser und größer und sonst was, macht das einen ganz anderen Unterschied, als wenn du sagst, das ist es jetzt und das ist fertig Funktional ist es das, weil da wirfst du die Leute halt einfach ins kalte Wasser, das ist sicherlich ein Punkt. 
Bei dieser Frage mit diesem Typus Mensch, der quasi eh nie zufrieden ist und die ewig gestrige Welt der nachtrauert. 

Überzeugung durch Mitnahme vs. Späne fallen lassen

[28:49] Ich bin da mittlerweile, oder was heißt mittlerweile eigentlich, also mich hat dieses Argument, dieses wir müssen die Leute mitnehmen ehrlich gesagt noch nie überzeugt. 
Sondern ich bin wirklich Fan von der Idee, wo gehobelt wird, da fallen halt einfach auf Späne. Und wenn dann jemand sagt so irgendwie, ja, ich möchte aber weiter mit meinem alten System arbeiten, dann kannst du das machen, aber halt nicht bei uns. 
Wir sprechen ja über diese Einführungssituation und… 

[29:13] Ich würde mir wünschen oder ja, ich glaube, es ist da dann auch die Aufgabe des Projektleiters bei den entsprechenden Fachführungskräften, also das liegt nicht mehr in der Macht des Projektleitenden, aber bei den entsprechenden Fachführungskräften dann tatsächlich auch dafür zu sorgen, so wir werden es nicht allen recht machen können, das ist weder wirtschaftlich noch der Rolle des einzelnen Mitarbeitenden angemessen, Sondern wir müssen da dann auch tatsächlich sagen irgendwie dieses Unternehmen bewegt sich mit dieser Veränderung, die wir haben in eine bestimmte Richtung und das kannst du gut finden und das kannst du schlecht finden, aber wir machen das halt eben trotzdem und diese, für mich ist das ein Ausdruck von schlechtem Management, wenn man wirklich bei jedem Thema es zulässt, dass das in epischer Breite von allen Leuten, die meinen dazu eine Meinung haben zu können, zu müssen diskutiert. 
Sondern ich bin wirklich der Auffassung, man muss… 
Das ist so eine Unternehmenskulturfrage dann auch. Also ich kann mir nicht vorstellen, dass wenn du so ein familiengeführtes Unternehmen bist, dass das da irgendjemand traute, wenn der Patriarch oben sagt irgendwie, wir machen das jetzt so, dann zu sagen, ja nee, das sehe ich jetzt aber anders. 
Klar, je anonymer das Unternehmen geführt ist, desto einfacher wird das dann hinten raus. 
Aber ja, ich bin da wirklich, nenn es alte Schule, Aber ich bin da wirklich kein Freund von diesem, wir müssen die Leute abholen, wo sie stehen und wir müssen es so lange vorkauen, bis es dann auch irgendwie jemand ohne Zähne gut essen kann. 

Gruppe identifizieren, die nicht mitkommen kann

Fabian:
[30:40] Also ich bin da bei dir, dass es gibt die, und das ist ja dann für beide Seite besser, die dann, wo man dann einfach irgendwann weiss, die können jetzt das nicht. 
Das kann ja ganz viele Gründe haben, oder? Also es kann emotionell sein, manchmal ist es auch intellektuell und so weiter, das glaube ich auch. 
Aber ich glaube, die Frage des Mitnehmens ist wirklich massiv eine Frage des Zeitpunktes, oder? 
Also den Fall, den du beschreibst, ist für mich einer, da bist du wirklich schon fortgeschritten in der Einführung und du merkst irgendwann, ja, jetzt gibt es wirklich ein paar, die da nicht mitkommen, auch beim dritten Versuch nicht. 
Und da sehe ich es auch so, weil das kann ja nicht an positiven Orten führen. 
Aber sonst glaube ich schon daran, dass du Wege finden musst, diese Gruppe klein zu halten. 
Und da gibt es ja dann auch Erfahrungen, wo du… Also ich habe da effektiv schon massive Überraschungen auch erlebt. Also auf den ersten Blick denkst du, ja, das ist jetzt sicher einer, der hier blockiert oder eine. 
Und dann merkst du, hey, nee, es ist genau umgekehrt. Das ist sogar auch jemand, der nach einer gewissen Anlaufzeit mit Begeisterung auf das Neue sich einlässt. 
Und ich glaube, diese Erfahrung führt dann zu diesem Mitnahme imperativ, oder? 

[32:04] Aber den anderen Fall gibt es auch und ich glaube, das ist auch, Das kann auch jedem passieren. Change gibt es ja nicht nur bei Systemen, sondern es kann auch sein, dass dir das passiert bei einer Reorganisation oder irgendeinem anderen Veränderungsprozess, wo du einfach sagst, da habe ich jetzt keinen Bock mehr mitzugehen. 
Und dann ist da, glaube ich, auch daran lieber ein schnelles Ende wie Schrecken ohne Ende. Also solche Sprüche sind manchmal tatsächlich gut, aber das kann schwierig sein. 
Das können schwierige Auseinandersetzungen sein und deshalb drückt man sich in der Regel wahrscheinlich dann auch davon, solche Dinge zu vollziehen. 

Mel:
[32:49] Ich glaube, damit ist auch das Thema umfassend und abschließend diskutiert für den Moment. 
Wir verabschieden uns jetzt in die Sommerpause, aber keine Sorge, ihr müsst nicht auf uns verzichten. 
Es wird auch in zwei Wochen eine Folge geben, die wir jetzt gleich noch vorproduzieren werden. 
Wir können auch schon mal anteasern, dass wir mit unserem Interview-Format Management by Project Insights auch im Sommer noch eine neue Folge produzieren werden. 
Wir verraten noch nicht, wer das ist, aber es wird cool und es wird diesen Zeiten angemessen. So viel kann ich schon mal anteasern. 
Und ansonsten vielleicht noch ein letzter Hinweis. Wenn ihr Social Media Nerd seid und irgendwie darüber informiert werden möchtet, wenn eine neue Folge erschienen ist oder wenn wir es mal wieder nicht schaffen planmäßig aufzunehmen, dann könnt ihr uns einfach auch neuerdings bei Twitter folgen, Management Bar Projects, Management abgekürzt mit MGMT, da findet ihr dann einfach über den Kurznachrichtendienst alle Infos zu den jeweils aktuellen Folgen. 
Was es sonst noch so gibt, jetzt wo Elon Musk das Ding nicht mehr kauft, kann man das ja auch ohne schlechtes Gemüse weiter nutzen. 

Fabian:
[33:58] Fantastisch. 

Mel:
[34:00] Soweit bis hierher. Wir wünschen euch einen fantastischen Sommer. 
Wenn ihr noch schon in den Ferien wart, hoffen wir, dass ihr schöne Ferien hattet. 
Wenn ihr noch fahrt, dann habt eine gute Zeit. 
Tragt Sonnencreme auf und wir wünschen euch das Allerbeste. Bis dann. 

Fabian:
[34:12] Macht’s gut.