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.