5 typische Fallstricke in IT-Projekten

Joel Kaczmarek: Hallo Leute, mein Name ist Joel Kaczmarek. Ich bin der Geschäftsführer von Digital Kompakt und heute habe ich den lieben Jörg Herbst an meiner Seite. Jörg, der ist Geschäftsführer von einer Firma namens Newcubator. Und Newcubator ist eine Agentur für Web-Anwendungen und mobile Apps. Und warum sitzt er heute hier, fragt ihr euch vielleicht. Das kann ich euch erklären. Der liebe Jörg hat über 20 Jahre Erfahrung, was IT-Projekte angeht. Und er und ich haben zu tun miteinander, weil er auch bei Makers und Shakers in meinem Business-Club ist. Also ihr habt jetzt schon mal über ihn gelernt, er hat großartigen Geschmack. Und weil er mir sogar dabei hilft, unsere Webseite neu zu relaunchen, weil ich natürlich in den Sessions mit ihm erkannt habe, was für Potenzial sich bei ihm versteckt. Das versteckt sich gar nicht, alle sehen es schon und ich habe es sozusagen auch entdeckt. Und deswegen arbeitet er auch für uns. So und auf dem Wege konnte ich... mir einen super Eindruck von ihm machen und weiß, dass er extrem gewissenhaft ist, dass er trotzdem innovativ ist und alles sich genau anguckt, dann habe ich gesagt, Jörg, können wir nicht mal eine geile Session machen, die wir mal wirklich podcasten? Dann hat er gesagt, yo, let's do it, was willst du denn machen? Dann habe ich gesagt, naja, wie wäre es denn, wenn wir mal so typische IT-Projekte Fallstricke nehmen? Dann hat er gesagt, yo, machen wir fünf Fallstricke über IT-Projekte. aus 20 Jahren Erfahrung, kann ich dir einiges erzählen. So, und da sitzen wir heute, von daher, lieber Jörg, man hört noch meine heisere Stimme von unserem gemeinsamen Live-Treffen auch vor kurzem im Business Club, also freut mich, dass wir auf so vielen Ebenen zu tun haben und bin gespannt, was du heute zu erzählen hast.

Jörg Herbst: Ja. Joel, vielen Dank erstmal für die Einladung, dass ich heute hier sein darf. Und natürlich möchte ich gerne ein bisschen was von meinem Wissen weitergeben, dass wir gucken, wo wir noch weiter zusammenarbeiten können.

Joel Kaczmarek: Sehr gut, also fünf Fallstricke. Fangen wir mal mit dem allerersten an. Also ich habe von dir schon gelernt, was viele Leute irgendwie versäumen, das hat es mir im Vorgespräch schon geflüstert, ist, dass irgendwie eigentlich gar nicht so richtig betrachtet wird, was wirklich gebraucht wird. Mal als ersten Fallstrick. Führ doch mal ein bisschen aus, was damit gemeint ist.

Jörg Herbst: Ja, wenn wir in Projekte reinkommen, ist es halt ganz oft so, dass wir mit Experten in den jeweiligen Unternehmen zu tun haben und die haben naturgemäß eine gewisse Betriebsblindheit. Die kennen ihre Geschäft sehr, sehr gut und sie kennen natürlich auch ihre Top-Kunden super, aber ihnen fehlt manchmal der Blick so für die Basissachen. mit dieser Software noch nie gearbeitet. Ich habe mit diesem Unternehmen noch gar nichts zu tun gehabt. Was ist denn das eigentlich? Das müsste doch alles ein bisschen besser erklärt werden. Warum gibt es hier fünf verschiedene Optionen und nicht nur eine, um damit zu starten? Was brauchen wir denn wirklich, um die Masse unserer Kunden abzuholen? Oder was braucht man vielleicht, wenn man die Software vielleicht auch außerhalb von Deutschland nutzen will? Gibt es da vielleicht einen ganz anderen Erfahrungsschatz, ganz andere Vorkenntnisse? Man entwickelt manchmal Features, die sind halt sehr, sehr speziell. Das betrifft vielleicht ein Prozent der User. Aber das Feature, was vielleicht 50 Prozent der User, die das noch gar nicht haben oder den Kunden noch gar nicht kennen, weiterhelfen. würde um da reinzukommen das wird nicht entwickelt.

Joel Kaczmarek: und jemand der das wie du schon lange macht wie heißt du dieses problem dann? also wenn jemand droht diesem fallstrick zum opfer zu fallen was machst du dann um dem zu entgehen?

Jörg Herbst: In der Regel versuche ich einfach, das Ganze nochmal so ein bisschen einen Schritt zurückzudrehen und zu sagen, wo ist der Markt dafür? Es gibt ja mittlerweile eine ganze Menge Methodiken dafür. Design Sprint ist so eine ganze Klassiker, wo man einfach mal Dinge verproben kann. Eine andere Option, die wir auch gerne mal anbieten, ist, dass man so ein A-B-Testing macht. Also man baut einmal die Option mit fünf verschiedenen Schaltern und sehr, sehr gut konfigurierbar für Experten. Und dann baut man parallel nochmal eine Option, wo es einfach nur eine Variante gibt oder eine Variante Rot oder Grün, in die man reingehen kann, um einfach das mit der entsprechenden Nutzerschaft zu testen.

Joel Kaczmarek: Was ist denn sonst mit so klassischen NutzerInnen-Befragungen? Also das Problem ist ja ganz oft, dass viele Unternehmen irgendwie gar nicht nah an ihren KundInnen dran sind. Also dass sie mit denen nie geredet haben oder zwar reden, aber gar nicht die Bedürfnisse kennen. Begleitet ihr sowas auch? Also ist es auch so Teil eurer Arbeit oder forderst du deine Kunden auf sowas zu tun? Ist es sinnvoll, um dem Thema zu entgehen? Wie ist es mit sowas?

Jörg Herbst: Grundsätzlich sind NutzerInnen-Befragungen natürlich immer sehr sinnvoll. Wir machen das nicht. Weil wir glauben, das ist einfach ein Wissen, was wir bei uns im Unternehmen nicht haben. Da braucht man schon Experten, weil der große Gefahr ist, man fragt seine Top-Kunden, mit denen man schon jahrelang zusammenarbeitet und dann ist das Ganze sehr biased. Die Fragen so zu stellen, dass sie wirklich offen beantwortet werden und nicht in irgendeine Richtung schon tendieren oder auch im Zweifelsfall eine Skala vorzugeben und das dann richtig auszuwerten mit entsprechenden statistischen Methoden und einem gewissen psychologischen Hintergrund, das ist nicht etwas, was wir haben. Aber wir ermutigen unsere Kunden immer dazu, das zu tun, wenn sie es nicht schon im Vorfeld getan haben.

Joel Kaczmarek: Und hast du mal noch so eine schöne, sage ich mal, Projektplanungs-Best Practice, was diesen Gedanken angeht? Weil wenn du sagst, okay, Fallstrick besteht darin, dass oft sich gar nicht gefragt wird, was wirklich gebraucht wird. Arbeitet ihr dann zum Beispiel mit so einer Art Pflichtenheft und baut das alles in Sprints zusammen, dass ihr sagt, okay, Projektlänge ist X und hier Pflichtenheft wird dann in der und der Reihenfolge abgearbeitet? Oder wie macht ihr das?

Jörg Herbst: Wir empfehlen eigentlich bei fast allen innovativen Projekten wirklich eine agile Vorgehensweise zu machen, einen sogenannten Minimal Viable Product zu bauen, was schnell am Markt ist und wo wir mindestens einen ersten sogenannten Beta-Test machen können. Also wo ausgewählte Benutzer dieses Produkt vorgeführt bekommen, wo vielleicht noch nicht alles funktioniert, wo bestimmte Sachen auch nochmal gefakt sind, aber wo man einen echten Eindruck kriegt, weil das, was wir aus der Nutzerbefragung kriegen, ist, selbst wenn sie sehr gut gemacht ist, nicht unbedingt das Verhalten, was dann wirklich erfolgt ist, wenn man die Anwendung in der Hand hat oder das Produkt in der Hand hat.

Joel Kaczmarek: Ja, manchmal ist es ja auch so, hat es nicht Steve Jobs damals gesagt, wenn ich die Leute gefragt hätte, was soll das Ei wohnen können, hätten sie gesagt, größere Willscheibe, so nach dem Motto, irgendeinen Spruch gab es da, genauso wie wenn die Mönche gefragt worden wären, wie kann ich das Schreiben besser machen, hätten die gesagt, andere Federn herstellen, wo dann aber Gutenberg den Buchdruck erfunden hat. Also ich glaube, ich weiß, was du meinst. Manchmal so, dass man anderes sagt, als man handelt, wo wir beim zweiten Fallstrick wären. Das passt ja, glaube ich, ganz gut, nämlich das Thema Testen. Klar kann ich jetzt mal testen, was bei den Usern ankommt, aber auch natürlich reine Funktionalität. Worin besteht denn der Fallstrick? aber ganz konkret?

Jörg Herbst: Der Fallstrick beim Testen ist, dass meistens damit viel zu spät gegonnen wird und dass es oft nicht systematisch erfolgt. Ganz oft erleben wir Projekte, wo wir sagen, ja, ihr entwickelt dann mal die Software fertig und dann können wir die ja bei uns testen. Dann kann man maximal noch funktionale Fehler finden und selbst wenn man die findet, ist es je später man die im Projekt findet, desto teurer ist es, diese Fehler zu beheben. Wir wollen eigentlich in dieser agilen Scrum-Arbeitsweise, sagt man, man möchte eigentlich nach jedem Phase ein potenziell auslieferbares Produkt haben und wir interpretieren das für uns so, dass dieses potenziell auslieferbare Produkt auch ein potenziell testbares Produkt ist. Also wo ich schon erstes Feedback nach wenigen Wochen kriege, wo ich sehe, werden die Features so angenommen, kann ich es so bedienen, ist die Schrift groß genug oder nehme ich eventuell in meiner Zielgruppe einfach die Leute nicht mit, weil ich einfach sowas wie zu kleine Schrift habe? oder ich habe Dinge nicht betrachtet, wie dass ich zum Beispiel Rot-Grün-Blindheit, was ja durchaus verbreitet sein kann und auf einmal verliere ich da ein ganz paar Prozent meiner Zielgruppe. Von daher empfehlen wir eigentlich, das Testen von vornherein mit in den Prozess reinzudenken. Wir machen das dann nicht nur in dem... im Sinne, dass es ein Endkundentest ist, sondern auch wenn wir unsere Software bauen, ist ein funktionaler Test immer ein Teil der ausgelieferten Software.

Joel Kaczmarek: Okay, also lerne ich schon mal draus. Ich kann natürlich funktional testen, aber das andere ist ja auch, was mit dem ersten Punkt eigentlich zusammengeht, konzeptuell zu testen. Dass ich eigentlich mal sage, das und das Feature, so wie das gebaut ist, kommt das überhaupt an? Macht das auch Sinn, so wie du es gerade beschrieben hast, mit der eine Edge-Case, der vielleicht ein Prozent der Zielgruppe betrifft? Muss ich den wirklich auf Fronten haben? Meinst du sowas auch?

Jörg Herbst: Ja, das ist auf jeden Fall wichtig. Also gerade, wenn ich im sehr innovativen Markt unterwegs bin, Du hast vorhin selbst gesagt, naja, wenn ich jetzt versuche, irgendwie ein neues Smartphone zu bauen oder ein neues Smartphone zu bauen, ja, dann sage ich, es muss irgendwie kleiner werden. Und das ist, glaube ich, ein großes Innovationshindernis, dass man im Grunde genommen sehr, sehr schwer ist, daran out of the box zu denken und das aber auch zu vertesten, ob diese These, die man dann hat, auch wirklich vom Kunden angenommen wird. Das muss Teil des Prozesses sein und das muss früh gemacht werden, weil dann kann ich mir im Winter hinten viel Aufwand sparen, wenn ich merke, okay, das Feature wird überhaupt nicht angenommen. Telefone ohne W-Scheiben funktionieren nicht.

Joel Kaczmarek: Lass uns zum dritten Fallstrick kommen. Du hast mir gesagt, viele würden gar nicht ihren Projekterfolg definieren. Was meinst du damit genau?

Jörg Herbst: Naja, klassisches Projektmanagement auf Time and Budget. Das heißt, ein Projekt ist dann erfolgreich, wenn ich einen Zeitplan eingehalten habe und wenn ich mein Budget eingehalten habe. Wir alle wissen, das trifft in den seltensten Fällen zu. Man hört gerade bei IT-Projekten sehr, sehr oft, dass die einfach out of budget sind, dass die Zeit leihen das zweite, das dritte Mal, dass irgendwie das Release irgendwie drei Monate später kommt als gedacht. Der andere Punkt, den ich aber an der Stelle sehe, ist, dass man sich erstmal Gedanken machen muss, kann ich in der heutigen Welt überhaupt noch mit so einem Mindset ein Softwareprojekt aufsetzen? Wir haben eine sehr, sehr agile Sache. Es gibt immer wieder neue Innovationen, die auf den Markt kommen. Ich kann meinen Markt vielleicht gar nicht abschätzen. Wie ist der in drei Monaten? Und wenn ich jetzt sage, okay, ich habe ein Budget von X und will damit in drei Monaten live sein, dann kann ein Projekterfolg aus unserer Seite durchaus sein, wenn wir sagen, okay, das Projekt war doppelt so teuer wie geplant, aber wir haben zehnmal so viel mehr Kunden. Und das einfach zu sagen, wann bin ich denn eigentlich erfolgreich für innovative Projekte? Das ist ein ganz wichtiges Kriterium. Es gibt verschiedene KPIs, die man machen kann. Das ist allgemein wahrscheinlich ein bisschen schwer zu definieren. Grundsätzlich würde ich immer sagen, was ist denn eigentlich die User-Interaktion? Wie viele Benutzer von dem potenziellen Markt benutzen mein Produkt? Wie oft wird es genutzt? Habe ich wiederkehrende Nutzer? Also das ist immer eine ganz gute Metrik. Man kann mit Marketing oft dazu bringen, dass die Benutzer das Produkt das erste Mal testen oder ich kann irgendwelche Promotion-Aktionen machen. Aber wenn ich wirklich wiederkehrende Nutzer haben will, egal ob es ein Consumer-Produkt ist oder internes Produkt ist, ist so die... Wiederkehrende Metrik ist das Wichtigste für mich.

Joel Kaczmarek: Wenn ich mich mal so umgucke, ich weiß, ich habe früher mal bei einer softwareorientierten Firma auch gearbeitet, da hatte ich auch mal den Eindruck, es geht immer um Budget und TTM, Time to Market. Also wie schnell ich quasi an den Markt komme mit meinen Features. Vor allem bei dem, was du gerade geschrieben hast, brauchst du ja auch eigentlich Testfähigkeit. Du brauchst ja so einen Vorher-Nachher-Blick, damit du es überhaupt der IT zu attribuieren kannst. Weil sonst könntest du ja sagen, es liegt am Marketing oder es liegt am Sales. Deswegen mal so aus der Praxis gefragt, wie viele Kunden sind bei diesem dritten Thema Projekterfolg definieren und dann natürlich eigentlich auch messen denn gut? Und was tun die so?

Jörg Herbst: Also ich muss ehrlich sagen, ich glaube, der Großteil unserer Kunden ist da nicht besonders gut. Die kommen aus einer klassischen Budgetplanung, das heißt, die machen eine Jahresplanung oder haben vielleicht so einen Fünfjahresplan. Dann wird das Projekt genehmigt, dann kommt es in einen Genehmigungsausschuss, wird vom Vorstand abgesegnet und dann setzen wir es um und dann wird es im nächsten Jahr umgesetzt und im übernächsten Jahr eingeführt. Dieses schnell auf Marktänderungen reagieren ist gerade in Deutschland nicht weit verbreitet.

Joel Kaczmarek: Agilität ist aber auch irgendwie so. das Stichwort der Stunde, hört man bei dir auch raus. Also bei allen drei Punkten, über die wir jetzt schon geredet haben, ist das so ein Faktor. Muss ein Unternehmen heutzutage eigentlich in der Lage sein, das, was du früher vielleicht in einem Jahr gebaut hättest, jetzt schon in einem Monat, wie du es beschrieben hast, so MVP-mäßig als Testballon zu bauen und dann den Eindruck zu gewinnen?

Jörg Herbst: Es muss auf jeden Fall in der Lage sein, relativ schnell einen Markteindruck zu kriegen. Ob das immer im Monat sein muss, will ich so nicht sagen. Aber wir können halt keine siebenjährigen Release-Zyklen uns mehr leisten.

Joel Kaczmarek: Wo wir zu einem weiteren spannenden Punkt kommen. Du hast gesagt, so ein typischer Fallstrick ist auch nicht ausreichend Transparenz in IT-Projekten zu haben. Beschreib mal und dann kommen wir, glaube ich, darauf, warum ich das irgendwie gleich ad hoc spannend fand.

Jörg Herbst: Klassische Projektsituation bei uns ist, man baut das Projekt. Team, die gehören dann dazu und damit sind ja erstmal alle Probleme im Unternehmen gelöst, weil man hat jetzt ein Problem, was man lösen wollte, das hat man erkannt, wir haben dafür ein Budget bewilligt und jetzt haben wir unsere ganzen Anforderungen irgendwie gesammelt, die haben wir diesem Projektteam gegeben und das Projektteam darf das jetzt lösen. Wenn das fertig ist, dann sind ja all unsere Probleme gelöst. Das ist so ein bisschen die Erwartungshaltung, die man dann gerade für Externe an der Stelle schürt. Es gibt sehr, sehr selten den Fall, dass die Projektzwischenergebnisse dann nochmal intern kommuniziert werden, dass Stakeholder da schon mal mit reingezogen werden, dass man sich auch allein Fachexpertise holt. Wie oft habe ich erlebt, dass wir im Grunde genommen ein Problem gelöst haben, was eine andere Abteilung auch schon mal gelöst hatte, was wir aber erst sechs Monate später erfahren haben, weil die ja in einem anderen Projekt waren. Und gerade in Großkonzernen passiert das immer wieder, dass man einfach nicht miteinander redet. Und das ist gar nicht mal unbedingt ein Organisationsthema, das ist manchmal ein Kulturthema. Es ist einfach nicht üblich, dass man sozusagen über die Interne, weil man ist jetzt ja in einem Projekt, das hat dann manchmal auch nochmal irgendwie so ein Code-Wort oder darf noch gar nicht so richtig sagen, ja, wir arbeiten jetzt daran. Aber was wir da genau machen, das will keiner wissen, weil eventuell muss man kritische Fragen beantworten und eventuell gibt es da auch Entscheidungen, die nicht jedem gefallen. Also redet man intern über das Projekt nicht, was man da macht. Und manchmal geht es natürlich wirklich auch um Geschäftsgeheimnisse, die da gefahrt werden müssen. Aber gerade intern ist es ganz, ganz wichtig, diese Transparenz herzukriegen. Also ich habe von Google gehört, dass die sehr, sehr viel Wert darauf legen, dass sie eine hohe Transparenz haben. Auch Cross-Funktional-Entwickler, die zu Google gehören, die sehen, was passiert irgendwo in der Mail-Applikation, auch wenn sie eigentlich irgendwo... in der Suche arbeiten.

Joel Kaczmarek: Ich kenne das. Irgendwie ist man als Unternehmen dann, glaube ich, schnell verführt, so eine Art Big Bang Launch zu machen. So, hey, liebes Team, Überraschung. Das Projektteam Alphabeta Tauri hat jetzt irgendwie ein Jahr lang an unserem neuen CRM-System, keine Ahnung was, Integrationsprojekt gearbeitet. Here it is. Bitte applaudiert und versäumt immer eigentlich vollkommen genau, wie du es sagst, mal reinzuholen. Okay, hätten wir mit dem Sales Team mal vorher geredet, wüssten wir vielleicht, dass diese und jene Funktion gar nicht gebraucht wird, uns aber so und so viel 1.000 Euro pro Monat kostet.

Jörg Herbst: Ja, in so eine Richtung gedacht. Und manchmal ist es noch viel schlimmer, wenn man so ein bisschen über Changement, nachdenkt ist das was vielleicht die geschäftsführung für das tolle neue feature hält und das große launch party macht sehen vielleicht andere mitarbeiter oh mein gott Was ist das jetzt? Muss ich mich damit beschäftigen? Damit soll ich jetzt arbeiten? Und die sind dann überhaupt nicht begeistert. Und dann ist statt großer Party die Stimmung eher auf dem Nullpunkt.

Joel Kaczmarek: Ja, zumal ja meistens die Leute, die in der Umsetzung sind, also ruhig in der Bütt, die sind ja viel näher dran an der Front. Die können ja in der Regel eigentlich viel besser sagen, was benötigt wird, wo wir wieder beim Thema Testen sind, wo wir wieder beim Thema Kundennähe sind. Also was machst du, wenn du sowas beobachtest im Projekt, dass das so abgekapselt geheim gehalten wird? Wie versuchst du diesen Fallstrick zu beheben?

Jörg Herbst: In der Regel versuchen wir intensiv darauf einzuwirken, dass wir ein Stakeholder-Meeting machen, was sehr regelmäßig stattfindet, wo wir Zwischenergebnisse... präsentieren. Und unser großes Mantra an der Stelle ist eigentlich immer, dass wir sagen, wir haben testbare Erfolge. Wir liefern Zwischenversionen der Software aus und zeigen das auch den Leuten, die an der Front sind. Und zwar nicht erst zum Big Bang Release, sondern im Grunde genommen nach vier Wochen. So sieht es aus. Manchmal sind das Screen Videos an der Stelle, wenn wir sie nicht live erreichen, aber einfach möglichst früh die Leute mitnehmen.

Joel Kaczmarek: Und was ist die Erfahrung bei dir? Wie wird darauf reagiert? Kriege ich so eine Kultur überhaupt gedreht? Du bist ja in der Sekunde Dienstleister, indem du halt sagst, hey, lasst uns das irgendwie breit kommunizieren oder sträuben die sich?

Jörg Herbst: Bei unseren Kunden muss ich sagen, es sind die Erfahrungen sehr positiv. Die Leute fühlen sich einfach mitgenommen und wir sehen in unheimlich nach außen starr wirkenden Strukturen eine Menge engagierter Mitarbeiter, die das machen wollen, die was verändern wollen und denen auch sehr konstruktives Feedback geben und sagen, das habt ihr euch vielleicht ganz gut gedacht, aber in der Praxis wird dieses Feature nie genutzt. Das skippe ich immer irgendwie, wenn ich das meinem Kunden vorstelle, weil das will der sowieso nicht. Natürlich gibt es auch mal Leute, die sagen, ja, warum macht ihr das? Wir konnten das doch bisher auch immer anders machen. Aber grundsätzlich ist unsere überwiegende Erfahrung positiv.

Joel Kaczmarek: Und auf der Führungsebene, die ja die Kultur eigentlich vorgibt, also wenn du da dem Projektleiter sagst, hier in deinem Stakeholder-Meeting, ey du, bring das mal dein ganzes Team, bring das mal nicht nur den fünf Leuten hier auf den Tisch, die gerade mit hier im Raum sitzen, sondern da solltest du alle mit reinholen, ist dann immer eher Ablehnung angesagt oder wird das angenommen?

Jörg Herbst: Zeit ist natürlich eine sehr wertvolle Ressource und gerade auf so einer Ebene ist es sehr, sehr schwierig, dann immer alle mitzukriegen. Aber wir sehen da gerade auch einen Wandel. Also mittlerweile gerade vom Top-Management wird die Unternehmenskultur geändert. Also wir sind weg von den ganz klassischen hierarchischen Strukturen, zumindestens da, wo wir auch mit innovativen Themen und innovativen Projekten unterwegs sind. Die wollen ihre Leute mitnehmen, die gehen auch runter. Also ich habe auch schon Formate erlebt, wo einfach der Geschäftsführer dann wirklich hingeht und auch sagt, ich gehe in die Abteilung, ich schaue mir das an, ich möchte auch, dass meine... Mitarbeiter wirklich ganz unten gucken, so wie sieht es im Lager aus, wie sieht unser Versand eigentlich aus und entsprechend nehmen sich die Leute dann natürlich auch mit so, wir führen jetzt hier die neue Logistiksoftware ein, wie kann die eigentlich funktionieren.

Joel Kaczmarek: Wenn du jetzt mal so die Erfahrung anzapfst, wir sind wieder beim Thema Time-to-Market, also alle Schleifen, die ich drehe, verlängern den Time-to-Market, ich komme später mit meinem Feature raus. Es ist aber manchmal besser investiert, diese cross-funktionale Expertise einzuholen, von der du gerade gesprochen hast und dafür vielleicht einen Monat Versatz in Kauf zu nehmen, als dass ich was baue, wo ich das nicht eingeholt habe und zahle ich dann hinterher die Zeche, in dem es viel länger dauert, weil ich es dann reparieren muss?

Jörg Herbst: Ich würde es fast noch schlimmer sagen. Also gerade wenn es wirklich innovative Themen sind, hat man ja einen ersten Eindruck. Und für den ersten Eindruck gibt es eben nur die eine Chance. Und wenn die ja nicht gut ist, dann wird man vier Wochen später die App gar nicht mehr installieren oder die Software überhaupt verwenden, weil man sich ja die schon mal angeschaut hat. Also in der Regel ist es mehr testen und dann vielleicht nochmal zwei, drei Wochen hinten dran zu hängen, schon eine gute Entscheidung.

Joel Kaczmarek: Ja, und ich finde auch ehrlich gesagt faszinierend, weil, vermute ich jetzt mal, korrigiere mich, wenn es falsch ist, dass du die Leute natürlich ganz anders anzündest für so ein Projekt, wenn sie den ganzen Weg begleiten versus wenn sie nur das finale Ergebnis sehen, oder?

Jörg Herbst: Auf jeden Fall. Die haben ein ganz anderes Commitment und merken, okay, wenn ihre Ideen da berücksichtigt werden oder selbst wenn sie einfach auch nur eine konstruktive Rückmeldung kriegen und sagen, ja, das haben wir nicht gemacht, weil das ist für deine drei Top-Kunden vielleicht ein Feature, aber wir hatten einfach nicht das Budget dafür, dann fühlen sie sich viel, viel besser abgeholt, als wenn sie in vorverendete Tatsachen gestellt werden.

Joel Kaczmarek: So, vier Fallstricke haben wir durch. Einer fehlt noch. Was ist das bei dir?

Jörg Herbst: Fünfter Fallstrick, den ich glaube ich in allen Projektteams sehe, was nicht software-spezifisch ist, ist Commitment im Team. Im Grunde genommen, wenn man zusammenarbeitet, dann muss man gucken, wie kann man Ergebnis liefern. Und ich sehe natürlich in unserer Rolle als Dienstleister gerne mal Situationen, wo die Schuldfrage viel zu früh gestellt wird. Es gibt naturgemäß bei solchen Sachen Probleme. Es gibt Dinge, die nicht so funktionieren, wie man sich gewünscht hat oder geplant hat. Dann wird oft gefragt, wer ist jetzt schuld? Dann wird das von einer Abteilung auf die andere geschoben. wird es auch gerne hin und her geschoben, so vom Dienstleister auf den Auftraggeber an der Ecke. Das bringt nicht weiter, das löst das Problem nicht. Wir versuchen das immer hinzukriegen, dass wir sagen, okay, wir wollen gemeinsam ein Ergebnis haben. Das heißt, es müssen alle an einem Strang ziehen. Und das heißt natürlich auch, beide Seiten müssen in irgendeiner Art und Weise ehrlich zueinander sein. Sie müssen sagen, okay, das Feature dauert länger, wir schaffen es einfach nicht oder wir können es nicht so bauen, wie wir es bauen wollten. Wir haben da einfach ein technisches Problem. Wir können bestimmte Vorgaben nicht liefern und bestimmte Informationen sind einfach im Unternehmen nicht verfügbar, von denen wir dachten, dass wir sie haben.

Joel Kaczmarek: Also wie bei den anderen Punkten auch schon, stelle ich fest, überraschend oft sind Fallstricke in IT-Projekten eigentlich kultureller Natur. Ist ja eigentlich ein Kulturthema. Wie wird mit Fehlern umgegangen und was hat man eigentlich für eine Zusammenarbeitsform, oder?

Jörg Herbst: Ich würde sagen, 95% aller Projekte scheitern an Kulturthemen und vielleicht 5% an technischen Themen. Krass.

Joel Kaczmarek: Echt, ja. Wie löst denn sowas auf, wenn du sowas beobachtest?

Jörg Herbst: Inhaltlich ist es natürlich immer das Thema, dass da auch Geld mit eine Rolle spielt. In dem Augenblick, wo man halt mit externen Partnern zusammenarbeitet, geht es ja wirklich gleich ganz konkret um monetäre Zahlungen. Und dann sind wir wieder bei dem Budget-Thema. Okay, es geht nicht so, wie wir uns das gewünscht haben und wir laufen vielleicht aus dem Budget raus. Die klassische Variante, um das aufzulösen, ist eigentlich immer versuchen, ein konstruktives Gespräch zu haben und von vornherein nochmal zu sagen, was waren denn eigentlich unsere Projektziele? Wie können wir jetzt unsere Projektziele anpassen unter den neuen gegebenen?

Joel Kaczmarek: Und ich sage mal, wenn man mit so einem Führungsstil unterwegs ist auf der Kundenseite, der offensichtlich keine Fehlerkultur enthält, wo dann natürlich die Mitarbeitenden irgendwie eigentlich eher versuchen, die Verantwortung wegzuschieben, wenn was Schlechtes passiert. Ist sowas für dich überhaupt heilbar? oder merkst du dann, das sind so Projekte, die bringst du irgendwie zu Ende und dann geht man eigentlich geschiedener Wege?

Jörg Herbst: Es kann sein, dass das Corporate Culture ist. dann ist es eigentlich nicht heilbar. Wenn es von oben kommt und da gelebt, etabliert und auch gewünscht ist, müssen wir uns auch voneinander trennen, weil ich glaube, dann haben wir unterschiedliche Art und Weise in der Vorstellung der Zusammenarbeit. Wenn es nur im Team liegt, aber eigentlich im Grunde genommen organisatorisch zu lösen ist, dann kann man sowas mal eskalieren. Hatte ich auch schon, dass wir sagen, okay, dann gehen wir jetzt mal eine Ebene höher und setzen uns einfach mal mit dem Abteilungsleiter oder dem Bereichsleiter zusammen und überlegen mal, was wollen wir denn? Weil machen wir uns nichts vor. Im Grunde genommen haben ja beide Partner, wenn man sich in so einem Projekt zusammenfindet, dasselbe Interesse. Jeder möchte ja eine funktionsfähige Software haben. Das wollen wir als Dienstleister und das ist der Kunde auch, sonst hätte er uns nicht beauftragt.

Joel Kaczmarek: Ich kann mir trotzdem vorstellen, dass du natürlich immer unter diesem Generalverdacht stehst als Externer, dass natürlich du zwar auch eine funktionierende Software möchtest, aber dass es für dich schon ganz okay ist, wenn es ein bisschen länger dauert, weil es dann sozusagen mehr Umsatz bringt. Ist das so ein Thema, dass man dann schnell reinrutscht, gerade wenn man Schuldfrage, was wir wieder eben hatten, diskutiert?

Jörg Herbst: Ich glaube, das ist bei unseren Kunden nicht das Thema. Ich glaube, wir leben ja aktuell natürlich auch in der Situation, dass schon viel Nachfrage nach Software eigentlich da ist. Und ich glaube, jeder Kunde, der so ein bisschen am Markt etabliert ist, der hat schon eine ganze Menge Themen, die bei ihm sind. Und ich glaube, der muss sich nicht künstliche Arbeit schaffen.

Joel Kaczmarek: Gut, also wir fassen nochmal zusammen. Fünf Fallstricke über IT-Projekte. Der erste war, was wird eigentlich wirklich gebraucht, sich das mal zu fragen und da die Agilität drin zu haben. Das zweite war zu testen und das früh und auf verschiedenen Ebenen. Der dritte Faktor war, den Projekterfolg überhaupt mal zu definieren und auch vielleicht ein bisschen breiter zu denken. Der vierte war, Transparenz in IT-Projekte zu bringen, damit man auch wirklich cross-funktional die Expertise der einzelnen Leute einholt und anzapft. Und das letzte war gerade das Commitment im Team und wie dann quasi eigentlich reagiert wird, wenn mal was nicht klappt. So, das mal als unser Fünf-Fallstricke-Thema heute. Hast du noch so einen Abschlusstipp, so einen Abschlusssatz, wo du sagst, wenn ihr euch das schon anguckt, folgenden Satz habe ich nach 20 Jahren für euch auch noch mit am Start.

Jörg Herbst: Wichtig ist, wenn man miteinander zusammenarbeitet und das ist immer unser Credo, wir wollen mit unseren Kunden arbeiten, wir wollen nicht für unsere Kunden arbeiten. Und es gibt ja diesen Begriff, dieses Dienstleisters, wo das Wort dienen drin vorkommt. Ich glaube, das ist keine Art und Weise, glaube ich, wo man wirklich einen Erfolg hat. Ich glaube, man muss schon zusammenarbeiten wollen und gemeinsam dann auch. Erfolge erzielen zu können. Ja, okay.

Joel Kaczmarek: Würdest du sagen, das, was du jetzt gesagt hast, betrifft auch die Zielgruppe darunter oder die, die du hast, umso mehr? Gibt es da so eine Abstufung oder ist das eigentlich über alle Unternehmensgrößen relativ gleich?

Jörg Herbst: Für ganz junge Startups, muss ich ganz ehrlich sagen, bin ich nicht der Experte. Ich glaube, da geht es noch viel mehr darum, Dinge auszutesten. Da geht es, glaube ich, auch noch öfter darum, zu scheitern. Ich glaube, das ist in unserer Zielgruppe dann einfach noch nicht so sehr akzeptiert. Aber tendenziell gilt das natürlich für den gesamten Markt.

Joel Kaczmarek: Gut, lieber Jörg, dann bauen wir mal darauf, dass viele Leute jetzt diese fünf Fallstricke vermeiden. Bestimmt freust du dich, wenn man die auch ein bisschen schreibt auf LinkedIn, oder? Also vielleicht hier auch mal die Einladung, sich mit dem lieben Jörg auszutauschen. Vielleicht haben wir noch welche vergessen, dann müssen wir nochmal einen Add-on machen. Machen wir nochmal fünf oder zehn, wer weiß. Aber ich hoffe, es sind nicht so viele. Für den Moment auf jeden Fall schon mal vielen, vielen Dank. Ich fand das sehr knackig und kompakt und man merkt, glaube ich, was ich meinte mit der ruhigen, gewissenhaften Art. Also vielen, vielen Dank.

Jörg Herbst: Vielen Dank für die Einladung.