Skillbyte Podcast #59: Mit Druck in IT-Projekten richtig umgehen

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Mit Druck in IT-Projekten richtig umgehen

// Inhalt //
01:26 - IT-Projekte sind oft schwierig und komplex
02:41 - Gründe für Druck in IT-Projekten
03:00 - IT-Projekte von Profis schätzen und durchführen lassen
06:55 - Druck im IT-Projekt heißt Zeitdruck
07:56 - Druck wird oft von oben nach unten weitergereicht
09:48 - Erfahrungen mit Druck von IT-Junioren und IT-Senioren
13:24 - Zeitdruck und Kostendruck
19:10 - Zeit und Kosten sparen durch fachlich kompetenten Product-Owner
20:43 - Druck im IT-Systembetrieb durch Ausfälle und Sicherheitslücken

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Es wurden einfach vorab oben beim Vorstand gut dazu stehen, Termine kommuniziert, egal ob sie es realistisch oder unrealistisch waren. Einfach aus der Luft gegriffen und die IT oder die Software. Jungs und Mädels müssen das dann ausbaden, müssen sich also quasi diesem Druck ergeben oder mussten sich dem Druck ergeben und sagen Okay, das ist der Endtermin, dieses Gesetz. Jetzt müssen wir gucken, dass wir irgendwas bis dahin schaffen. Ich finde, sowas muss halt nicht sein.

Herzlich Willkommen zur Sky Podcast Episode Nummer 59 Mit Druck in den Projekten richtig umgehen. Abonniert unseren Podcast um mehr spannende Themen aus dem Technology Umfeld, den er als Fachkraft oder IT Entscheider seid. Wenn ihr eine höhere Frage habt, schickt uns gerne eine Email an Podcast skillbyte Wir freuen uns immer über Bewertungen und ganz besonders über Weiterempfehlung dieses Podcasts an eure Freunde und Kollegen, die ebenfalls im alten Sektor tätig sind. Ich bin heute hier mit Masiar. Hallo Masiar. Du bist ja mein Stammgast. Wunderbar, dass du heute wieder dabei bist. Ich freue mich sehr, mit dir über das Thema Druck mit Projekten zu sprechen, weil du ja auch mehrere Dekaden Erfahrung in Projekten hast und sicher die eine oder andere Drucksituation erlebt hast.

Ja, das ist tatsächlich wahr.

Hätte mich auch gewundert. Die Sache ist ja, die Projekte sind individual. Projekte sind schwierig. Ich habe mal einen den Chaos Report der Standish Group aus den USA aufgerufen und da bin ich zu den Zahlen gelangt. 52 % aller IT Projekte erfüllen die Anforderungen und Wünsche nicht. Also das was ursprünglich gefordert war von der IT Lösung konnte nicht umgesetzt werden. 90 % sind ein Totalausfall. Ich nehme an, damit sind Projekte gemeint, die einfach ohne Ergebnis eingestellt werden. Und nur 29 % der Projekte werden wirklich als erfolgreich bezeichnet. Also wahrscheinlich zeitlich okay. Budget okay und die Lösung macht was sie soll hinterher. Wir als alte Berater arbeiten natürlich ohnehin in IT Projekten, die eher schwierig sind, die auf dem kritischen Pfad liegen für die Unternehmen oder wo wir einfach schon verzögerte Projekte unterstützen. Das heißt, wir arbeiten sowieso schon in Projekten, die tendenziell schon gelb sind im Chart und nicht mehr ganz grün. Sonst würde man uns nicht anrufen. Warum sage ich das alles? Das Risiko in den Projekten ist relativ hoch und es entstehen häufig diverse Drucksituationen, über die wir heute sprechen müssen.

Insbesondere wie man damit umgehen kann und wie man sich da richtig verhält oder besser verhält, als einfach in blanke Panik zu verfallen. Hast du eine ganz besondere Situation erlebt, die dir jetzt sofort einfällt beim Thema Druck in Projekten?

Also es gibt verschiedene Gründe, warum überhaupt so eine Drucksituation entstehen kann. Das meiste, würde ich sagen, ist selbst gemacht, wird nach dem konkreten Beispiel gefragt. Ich habe mal für ein Unternehmen aus der Medienbranche gearbeitet und diese alteingesessenen Unternehmen haben noch ein anderes Verständnis von der IT. Sie können nicht wirklich IT Projekt und deren Komplexität einschätzen und wissen auch nicht, was das bedeutet. So ein Projekt von der Zeit her einzuschätzen, das heißt, es wurden einfach vorab, um beim Vorstand gut dazustehen, Termine kommuniziert, egal ob sie realistisch oder unrealistisch waren. Einfach völlig aus der Luft gegriffen und die IT oder die Software Jungs und Mädels müssen das dann ausbaden, müssen sich also gerade diesem Druck ergeben oder mussten sich dem Druck ergeben und sagen Okay, das ist der Endtermin, dieses Gesetz. Jetzt müssen wir gucken, dass wir irgendwas bis dahin schaffen. Ich finde, sowas muss halt nicht sein. Das ist auch mit ein Grund, warum Menschen oder oder Entwickler aus IT unzufrieden werden. Viele. Ich bekomme das in vielen Bewerbungsgesprächen mit, dass immer mehr oft dieses Thema Work Life Balance geachtet wird.

Wenn irgendwann mal Druck entsteht, weil es wirklich notwendig ist, kann ich das auch irgendwo verstehen. Und da kann man auch erwarten, dass das alle mit ins Boot springen und das Ding rocken. Aber so selbstgemachte Probleme, die nicht sein müssen, das geht glaube ich, nicht mehr gut. Das kann man heutzutage nicht mehr machen.

Das heißt im Grunde ein ganz wichtiger Hinweis an die IT Entscheider wäre hier, dass man die Projekte von Menschen durchführen lassen sollte, die schon mal Projekte gemacht haben und generell wissen, wie man so was macht. Die klassischen Branchen, die sind ja eher, ich sage mal das Wasserfall Modell gewöhnt oder die starten oft mit einem Zieldatum eines Projekts, wie du das gesagt, das eine bis dann und dann muss es fertig sein. Und dann legen wir mal los und sind eben nicht diese agile Vorgehensweise gewohnt, dass man erst mal die Anforderung sammelt, dann die wichtigsten Anforderungen priorisiert und dann nach und nach diese abarbeitet und quasi im zwei Wochen Rhythmus guckt Wo stehen wir denn? Und das dann berichtet an den Vorstand oder an den Geldgeber, sondern die starten direkt vom Ende her. Und das ist ziemlich frustrierend, auch für die Mitarbeiter der IT Abteilung oder der Society Abteilung. Jeder aus diesem Bereich weiß, dass das so nicht funktioniert.

Also die Devise ist wirklich acht Leute dransetzen, die ein bisschen Erfahrung haben und die so ein Projekt auch mal ungefähr abschätzen können. Das entspricht zwar nicht dem agilen Vorgehen heutzutage. Scrum, das ist auch irgendwie, da hat man schon ein paar Mal drüber gesprochen. Das ist halt kein Hammer und nicht alles. Nagel Wenn du eine bestimmte Software mit einem bestimmten Funktionsumfang haben willst, dann ist eventuell. Ein hundertProzentig agiles Vorgehen ist nicht geeignet. Man muss sich mal ein bisschen zurück und vergegenwärtigen, wie das entstanden ist. Das ist daraus entstanden, dass man gesagt hat Wir können nicht alles vorweg planen, weil die Zeit ändert sich. Viele, viele Kunden wissen noch nicht mal, welche Anforderungen sie eigentlich an das System haben, geschweige denn sie denn im Vorfeld formulieren können. Und das ändert sich, sobald man die Software gesehen hat und damit rumgespielt hat. Deswegen hat man gesagt Wie vermeiden wir zeigen alle zwei Wochen irgendwas, was wir erreicht haben und dann kann man nochmal diskutieren Ist das richtig so? Will man das anders haben? Und dass man so agil und iterativ herangeht und das Ganze irgendwie zu einem Erfolg bringt.

Aber ein wichtiges Feature, was man halt auch vergisst, ist Das Ding ist in MVP entwickelt worden, dass man sagt okay, wir wollen ein Produkt herausbringen, was die minimale Funktionalität, die es haben muss, hat, damit der Kunde schnellstmöglich drauf kann, Feedback geben kann. Und dieses Feedback ist eigentlich das Gold, was wir suchen, um das wieder umzusetzen. Aber es wird häufig der Fehler gemacht, dass wir die Zeit umgerechnet. Ja, und trotzdem will man agil arbeiten. Das passt halt nicht, denn man will einen vollen Funktionsumfang von irgendwas haben und fängt aber an, agil zu entwickeln. Irgendwann geht das Geld dann aus und da kommen wir wieder auf die Druck Position zu sprechen. Wenn es dann eng wird und ein gewisses Budget aufgebraucht ist, ohne die vorgestellten Ergebnisse zu haben, dann kommt Druck rein.

Der meiste Druck in Projekten, der mir so entgegen geschwappt ist, kommt eben durch Zeitdruck. Wann entsteht Zeitdruck, wenn gar nicht mal so Budget Druck, sondern wirklich Zeitdruck? Wenn eine Software zu einem gewissen Event zum Beispiel fertig sein muss, eine Wahl oder ein Sportevent? Der Termin ist ja dann nicht verschiebbar, das heißt, du musst da fertig sein. Wenn die Software eine Woche später fertig wird, ist sie quasi wertlos. Und dann bei der Planung macht man oft den Fehler, dass man nur vom FAT ausgeht. Ach das, die Komponente dauert drei Tage, die Komponente fünf Tage und ist dann erstaunt, wenn irgendwas länger braucht, weil das man Probleme mit der Datenbank hat und einfach zwei Tage verbrennt um die Datenbank richtig anzusprechen, weil es irgendwie ein Treiber Problem gibt. Und solche nicht sichtbaren Probleme gibt es eigentlich immer in Projekten, das plant halt niemand ein. Daher auch wieder Erfahrung beim IT Projektmanagement. Man sollte da einen ordentlichen Puffer 30 bis 50 % Aufschlag auf den besten Pfad mindestens nehmen und da bei halbwegs realistische Einschätzung zu machen.

Jetzt entsteht dieser Druck ja oft nicht von den Entwicklern her, sondern der Projektmanager bekommt Druck von oben. Wie du sagst, der Vorstand sagt Ja, aber wir haben doch geplant. Am ersten ersten ist das Ding fertig und unser Budget läuft dann auch aus und so, dann drehen die sich natürlich zum Projektmanager um und sagen Warum ist das nicht so? Und jetzt? Erfahrene Projektmanager erklären das dann nicht so erfahrende Projektmanager geben diesen Druck dann an das Team weiter und glauben Entwickler unter Zeitdruck denken schneller, was natürlich nicht der Fall ist. Ich weiß nicht, wie du das erlebt hast. Das wirkt dann eher so demotivierend. Es passiert auch nur, also diese Weitergabe von Druck häufig, wenn die Projektmanager eben nicht so viel Erfahrung haben oder hat der IT Reifegrad des ganzen Unternehmens noch nicht so hoch ist?

Ich möchte nur kurz berichtigen nicht nur Unerfahrenen passiert das, sondern auch erfahrenen hörigen Projektleitern. Also man muss auch mal den Schneid haben, die zuzuschneiden sagen no way, nee, das muss anders angegangen werden.

Ich kenne das eher von Quereinsteigern, die andere Projekte geführt haben und sagen Ja, IT Projekte ist ja so ähnlich. Häufig sind Entwickler ja intrinsisch motiviert und versuchen schon ihr Bestes zu geben. Ich weiß nicht, ob das in anderen Branchen auch so ist. Und manchmal entsteht so dieser Glaube. Ich muss sie nur ordentlich aufscheuchen, dann arbeiten die schneller. So aber häufig ist es ja so, dass die Ziele vielleicht nicht klar sind oder sich die Prioritäten andauernd ändern. Das kennst du bestimmt auch. Heute ist das das Wichtigste. Nächste Woche ist das das Wichtigste. Also dass du quasi ein bewegendes Ziel andauernd anspielst. Und dann wird es halt sehr schwer, da dann auch immer zu liefern. Was tut man hier? Also wenn man jetzt als Entwickler merkt oder als IT Fachkraft merkt, oh, ich krieg hier Druck von oben und ich werde hier getriezt, also zu Überstunden gedrängt und manchmal geschieht das auch so ganz subtil. Ja, bist du bis Freitag fertig oder so? Und da habe ich schon beobachtet, dass dann so die Schere aufgeht zwischen den erfahrenen Entwicklern und den noch nicht so erfahren und Entwicklern.

Ich weiß nicht, was du da beobachtet hast.

Ja, also die, die das schon mal mitgemacht haben, die reagieren da natürlich ganz anders drauf als junge Leute, die gerade angefangen haben. Die denken, das ist dann immer so, auch das aus Erfahrung in Bewerbungsgesprächen. Kollegen, die jetzt gerade ihre ersten Jahre hinter sich haben und dann jetzt wechseln und explizit dieses Thema ansprechen, weil sie das halt erlebt haben in dem aktiven Unternehmen mit Überstunden, Wochenendarbeit und so weiter. Macht sich irgendeiner verschätzt hat, falsche Versprechungen abgegeben hat oder oder oder.

Ich möchte noch mal sagen, es geht hier nicht darum, dass man mal eine Überstunde macht oder mal einen Samstag ein Deployment macht. Das kann ja durchaus auch im normalen.

Es gehört.

Dazu. Genau so geplant. Es geht aber darum, dass sich das so einschleicht und so ein Dauerzustand wird. In der Spieleentwicklung spricht man davon Crunch time, dass man wirklich zwei, drei Monate bevor das Spiel dann erscheinen soll, sagt man allen Mitarbeitern so Verabschiedet euch von euren Familien, nehmt die Zahnbürste mit ins Büro. Wir bringen das jetzt fertig, zu welchem Grad auch immer.

Abschließend euch und euren Freunden.

Das habe ich wirklich schon mal gehört. Ich habe ein paar Freunde, die arbeiten in dem Bereich und da wurde das teilweise regelmäßig so kommuniziert, weil in dieser Branche ist das Bestandteil sozusagen. Wahrscheinlich ist das gar nichts Außergewöhnliches.

Wahrscheinlich wird das aber auch entsprechend versüßt mit Schmerzensgeld und ich weiß es nicht. Ich habe da keine Erfahrungen aus der Branche, aber das kann ich mir vorstellen.

Auch da glaube ich mal so, mal so, ich habe beobachtet, wenn dieser Druck, dieser Zeitdruck runter gegeben wird vom Projektmanagement, dann ist es häufig so, wie du schon sagst, die jungen Leute oder die Leute, die nicht so lange dabei sind, die flippen so ein bisschen aus und versuchen ganz panisch Pläne umzusetzen, die auch unmöglich sind. Und die Erfahrenen werden halt eher ruhig und stellen mal ein paar Fragen. Also okay, wenn der Zeitplan knappes was können wir denn weglassen? Was ist denn das Ziel jetzt dieser Iteration? Können wir Anforderungen später noch umsetzen, die jetzt nicht so super wichtig sind?

Zum Beispiel unnütze Scrum Spielchen?

Nein, einfach Funktions Blöcke die man danach in Ruhe umsetzen kann. Also oft hast du ja in der Software so einen kritischen Pfad. Ein paar Sachen sind halt Bonus und dass man die dann auch sauber identifiziert, dass man alles aufschreibt und dann auch entsprechend priorisiert, das halte ich für sehr viel wichtiger, dass man weiß, was ist denn wirklich wichtig? Anstelle versucht alles zu machen.

Tatsächlich die Ruhe bewahren und mal einen Schritt zurück zu machen und zu überlegen wie kann man das jetzt lösen? Die richtigen Fragen stellen, auch von mir aus einfach auch Zeit nehmen, wo man sich einfach komplett vom Geschehen zurückzieht irgendwo und dann in so einer Art Workshop wirklich konstruktiv überlegt wird Was kann man da tun?

Die Gedanken sortieren und auch hinterher klar rausgehen und dann wieder sozusagen einen Plan erstellt haben, wie man diese neue Deadline oder diese alte Deadline mit vielleicht reduziertem Funktionsumfang doch noch schaffen kann. Aber erst mal Gedanken sortieren und einen Plan machen, das würde ich auch sagen. Das ist auf jeden Fall der Senior Ansatz auch hier.

Wie gesagt, das Hauptziel von Scrum ist, mehr Kommunikation zu fördern. Und auch in solchen Situationen gilt Kommunizieren hin, mit allen Stakeholdern zusammensetzen, oft Dinge auch falsch angehen. Wenn man mit den ursprünglichen Kolleginnen und Kollegen spricht, die entsprechendes Feature oder ein entsprechendes Produkt haben wollen, mit denen sich nochmal zusammensetzen, vernünftig reden, dann findet man Lösungen, so meine Erfahrung.

Ja, genau. Also einfach im Grunde Ziele klar haben und Prioritäten klar haben, wenn man das mal so zusammenfassen möchte. Genau das wäre das Wichtigste, wenn Zeitdruck aufkommt und sich nicht verrückt machen lassen. Das wäre unser Tipp. Eine weitere Form von Druck neben dem Zeitdruck. Zeitdruck ist meiner Ansicht nach der häufigste Druck, der nach unten weitergereicht wird, ist dieser Kostendruck. Also die Projekte, insbesondere Verzögerungen in Projekten erzeugen natürlich oft erhebliche Mehrkosten. Aber dieser Kostendruck äußert sich meistens darin, dass notwendige Hardware oder Software nicht beschafft wird. Kennst du bestimmt auch. Irgendjemand sagt okay, mit der und der Software, die kostet jetzt vielleicht paar 100 €, bin ich aber schneller. Auch da muss man oft ewig rum argumentieren und das versickert dann so in den Kanälen. Oft kann auch der Projektmanager nicht entscheiden, ob eine Softwarelösung oder eine zusätzliche Software wirklich hilft oder ob die nötig ist oder nicht. Und der Projektmanager versteht die wahren Kosten zum Beispiel eines schlechten Laptops nicht. Wenn ein Entwickler einen langsamen Laptop hat und immer wartet und damit zwei Jahre arbeiten muss, dann am Ende.

Wenn man das mal hochrechnet, hätte man ruhig den super guten Laptop kaufen können und der wird dreimal bezahlt gewesen, einfach durch den Produktivitätsgewinne.

Das ist ein Phänomen, was mir am Kopf geht, wie oft das wirklich ein Thema ist. Vernünftige Hardware, wo du erwiesenermaßen nachgerechnet, je nach Komplexität des Projektes eine Stunde Zeit am Tag sparst, weil einfach der Turnaround viel schneller ist, wenn du Sachen entwickeln und testen musst und das ist nichts im. Also die Kosten dafür für eine bessere Hardware im Vergleich dazu ist es absurd eigentlich.

Ich glaube, dass es auch wieder so eine Scheinrechnungen ist. Vielleicht Unternehmen, die nicht so viel Zeitverständnis haben. Die denken ja, Laptop ist Laptop. Die sehen nicht, dass es da signifikante Unterschiede gibt. Und warum soll der eine Laptop kostet 1.000 €, der andere 4000? Ja gut bei 3.000 €, wenn ich dem nur den 1.000 € Laptop gebe. Aber dass der dann jeden Tag halt die Stunde verliert, das erscheint halt nicht auf meinem Zettel.

Genau.

Sondern dann ist er halt einfach langsamer. Aber das ist dann sein Problem, so ungefähr. Und das ist natürlich auch zu kurz gesprungen und dieser Kostendruck wirkt sehr demotivierend. Dann oft auf die IT Leute, weil die halt sagen, ich habe hier mit dem. Langsam Laptop komme ich nicht so schnell vorwärts und ich warte die ganze Zeit und stehe nur an der Kaffeemaschine. Vor ein paar Jahren war das zum Beispiel ein Thema, wenn du einen zweiten Monitor haben wolltest. In vielen Großunternehmen musste man das argumentieren noch und nöcher. Ich glaube, das Ding ist heute durch. Das hat jeder begriffen, dass das ein unheimlicher Produktivitäts gewinn ist.

Bin mir nicht sicher, da.

Schon ein großer Monitor oder zwei normale Bildschirme habe ich jetzt schon an vielen Arbeitsplätzen gesehen.

Ich spreche von zwei groß getrennt. Geht es um zwei Großen, ist ein großer statt zwei kleine.

Auf jeden Fall ein zweiter Bildschirm. Dass der einen Vorteil bringt, glaube ich, dafür hat sich auf jeden Fall durchgesetzt. Und auch bei verschiedenen Weiterbildungsmaßnahmen muss man diskutieren, ob man das macht. Klar, das muss man immer schauen, ob sich das dann auch für die Firma auszahlt. Aber auch da habe ich schon erlebt, dass Leute Kleinstbeträge von Firmen nicht erstattet bekommen haben oder die Firma das nicht sich damit nicht beschäftigen wollte, weil sie einfach sagt Ja, Kosten, Kosten, Kosten. Und die 50 € will ich jetzt nicht auf meinem Projekt Budget verbuchen oder so.

Dass wir den Kosten aber eine andere Ebene nehmen du einfach mal ein Budget und nicht mal ein fest gesetztes Datum hast oder einfach nur so und so viel Geld für das Projekt und das es aufgebraucht oder nahe dran aufgebraucht zu werden. Ohne das Mindestmaß an Feature zu haben. Das ist halt auch eine Drucksituation, was sich dann wieder in Zeitdruck ausdrückt. Wo ich jetzt unterwegs war in einem größeren Unternehmen, wenn mal so ein Projekt aufgebraucht worden ist, dann wurde halt argumentiert, warum, wieso, weshalb, warum man noch mehr braucht und dann hat man das bewilligt bekommen, wenn das Projekt wichtig genug war oder halt nicht. Da war jetzt halt nicht so der Druck so groß, dass es auf die Entwickler dann zurück kam. Aber was ich gesehen habe ist, wenn du jetzt aus anderer Sicht wir haben das jetzt über Firmen gesprochen, wo du da sitzt und irgendwas entwickeln musst als Entwickler für das Unternehmen, eine Webseite, ein eigenes Produkt, was auch immer sage. Das ist aus unserer Sicht als Dienstleister habe ich auch oft schon gesehen bei befreundeten Unternehmen, die sich auf Festpreis Projekte einlassen.

Das heißt im Vorhinein Pflichtenheft abschätzen, was kostet das? Und da Sicherheits Aufschlag und dann aber das ist oft schiefgegangen und schiefgegangen, heißt das Geld wurde aufgebraucht, Zeit wurde aufgebraucht und am Ende vom Lied okay, wenn wir das jetzt nicht schaffen, dann stehen meistens auch noch irgendwelche Strafgebühren dran, wenn man den Vertrag bis dann nicht erfüllt. Und dann heißt es so man ran Abschied Wort. Und deswegen habe ich gesagt, diesen Druck, weil das ist echt keine schöne Situation für keinen. Deswegen haben wir uns über das beschlossen. Wir machen nur Termin Material.

Du musst ja dann auch. Wenn du so ein festes Budget hast, musst der quasi die Features im Vorhinein festlegen. Und dann bist du ja nicht mehr agil, weil dann sagt der Kunde Das möchte ich aber noch haben und sagt sehr gut, dann wird es teurer. So und dann bist du mit dem bist du immer dran. Also kenne ich das aus.

Fixpreis.

Projekten die gar nicht so Fixpreis sind am Ende, weil dann hin und her gerechnet wird.

Bis zum Change Management, was dann wieder ätzend ist.

Also da weiß ich nicht, ob das so gut ist. Aber meine interessante Frage an dich Wenn du ein festes Budget hättest, um irgendwas umzusetzen, würdest du dann lieber mit vielen Leuten schnell ans Ziel kommen wollen? Oder würdest du lieber langsam eine Truppe handverlesene Leute zusammenstellen?

Verlangt man als Unterlegener.

Würde ich auch machen. Das ist viel wahrscheinlicher, dass du da ein erfolgreiches Projekt hinstellst als husch husch mit maximaler Personenzahl.

Bei diesen eigenen Projekten. Eine Bitte, ein Flehen an Unternehmen, wenn ihr agil und Scrum und so weiter macht, bitte stellt einen Po, der auch fachlich Rede und Antwort stehen kann, so oft erlebt. Da wird einfach jemand als Po genannt und einfach weil er da ist oder keine Ahnung. Um in Anführungsstrichen dann zu sagen Ja, wir, wir sind Scrum agil unterwegs, alles super. Aber ich habe es echt selten erlebt in Projekten, dass oder war der wirklich fachlich Ahnung hatte.

Oder wenn er keine Ahnung hat, muss er jemanden an die Seite gestellt bekommen, der vom Fachbereich na ja.

Also wenn man das macht, dann weiß ich im Gespräch nicht wie es kein riesen Freund von diesem Vorgehen. Es hat schon Sinn und Zweck warum und wieso eine Rolle oder das System eingeführt wird. Da muss man sich auch dran halten. Weg von diesen Spielchen. Mehr zu dem Fachlichen.

Das sehe ich auch immer als total wertvoll an, es gibt da Posts, die sich wirklich dahinter klemmen, also Product Owner, die sich wirklich dahinter klemmen und dann auch den Fachbereich in Anführungszeichen nerven und da die Informationen einholen, sodass man auch Arbeitspakete hat, an denen man arbeiten kann und nicht, wo der Entwickler jetzt quasi losgehen muss, um alle Informationen zusammenzutragen. Ich nehme an, das euch zu verhindern, richtig?

Ja, genau. Genau.

Also das steht dann in dem Ticket drin. Bla, bla, bla umsetzen. Und du weißt. Nicht.

Genau zwei Zeilen dürfen das. Okay.

Abnahme, Kriterium oder Ticket bla bla bla umsetzen, Abnahme, Kriterium bla bla umgesetzt.

Ja.

Das ist ja zwei Drucksituation, Zeitdruck und Kostendruck bei der Planung und Umsetzung von Projekten. Es gibt natürlich auch Drucksituationen im wirklichen IT System Betrieb um zum Beispiel mal System Ausfälle zu nennen oder auch wenn Sicherheitslücken auftreten. Das habe ich auch schon häufig erlebt. Also System Ausfall ist, wenn kritisches System ausfällt, ist das natürlich häufig mit hohen Verlusten, sei es jetzt finanzielle Verlusten oder auch das Ansehen des Unternehmens. Kann man sich vorstellen. Wenn Facebook ausfällt, ist es deren Außenbild nicht förderlich. Druck entsteht dann, weil alle Betroffenen gleichzeitig mit Argusaugen auf die IT gucken. So, wann kriegst du das wieder an den Start? Im Prinzip wie bei der Formel eins Wenn der Mann mit dem Tank Stunden zu lange braucht, gucken auch alle den an und der schwitzt dann. Und genauso ist es bei System Ausfällen mit der IT Abteilung.

Man kann schon darauf vertrauen, dass die Jungs ihren Job machen und auch so oft gesehen, wo dann plötzlich der Vorstand hinter einem steht und und ja kann ich schon mal sehen. Und läuft es so?

Ich kenne das, dass das Telefon nicht mehr aufhört zu klingeln und man im Grunde man ist so hin und hergerissen zwischen Ich muss das jetzt kommunizieren und Ich muss aber eigentlich auch eine Lösung entwickeln. Auch da finde ich, sieht man den Seniorität grad von IT Fachkräften sehr gut. Die Veteranen, die werden dann ganz ruhig, stellen das Telefon auf stumm und überlegen okay, wie kriege ich den System Ausfall geritzt? Und neben Stift und Papier und in Ruhe überlegen Sie sich, okay? Das ist die Situation. Das und das kann man angucken und gehen ein quasi strukturiert die einzelnen Möglichkeiten durch und schauen wie kriege ich das System wieder an den Start? Die nicht Veteranen oder die jüngeren Kollegen, die flippen oftmals aus, gucken panisch in verschiedene Lock fails. Man weiß nicht was man kommuniziert davor den Vorstand oder den Ansprechpartner. Den Projektmanager füttert man mit irgendwelchen technischen Details, die der gar nicht wissen will, weil das ja wiederum seine Zielgruppe nicht versteht. Da kommt auch sehr viel Druck auf. Ideal denke ich, ist es, wenn man ruhig bleibt, hier vielleicht eine Person aus dem Team benennt, die das dann immer kommuniziert, an den Projektmanager oder an die Stakeholder.

Die darf das Telefon eingeschaltet haben und der Rest des Teams analysiert in Ruhe das Problem und entwickelt eine Lösung. Weil noch mal unter Druck denken Menschen nicht schnell ab, sondern es kommt höchstens zu mehr Fehlern. Wie ist da deine Erfahrung?

Eigentlich genauso. Ruhe bewahren ist immer angesagt. Gerade jetzt. Neulich wieder mit Lockwood J. Panik bringt nix. Na ja, klar muss man das Ding stopfen, aber es machen jetzt auch nicht Leute. Tausende Hacker, um dein Unternehmen sofort auseinander zu nehmen. Dann lieber mal eine Stunde überlegen, wie du es eben schön, dass das neue Stück Papier in die Hand nehmen. Was muss ich tun? Vernünftige Kommunikationsstrukturen überlegen und dann konzentriert abarbeiten?

Na, das ist ja das Thema Sicherheitslücken, also System. Ausfälle erzeugen natürlich Druck, Sicherheitslücken genauso. Da ist das System im Grunde noch nicht ausgefallen oder hoffentlich noch nicht ausgefallen und auch noch nicht kompromittiert. Bei den Sicherheitslücken finde ich immer du, die treten halt irgendwann auf. Also das kann am Wochenende sein, das kann um 4:00 nachts sein. Es kann bei System Ausfällen natürlich auch passieren, aber bei Sicherheitslücken, das ist halt nicht planbar im Grunde. Ich weiß nicht, wie deine Erfahrung ist. Ich habe schon den Eindruck, dass nach der DSGVO Novelle die Unternehmen schon jetzt sehr viel Angst davor haben, Sicherheitslücken zu haben, oder? Deutsche Unternehmen haben da sehr viel Angst, weil man diese Vorfälle ab einem gewissen Schweregrad muss man glaube ich melden. Und diese Meldung sorgt halt für Sichtbarkeit nach außen und für extrem hohen Stress beim Vorstand des Unternehmens oder bei den Vertretern des Unternehmens, weil halt dann Unternehmen XY meldet. Einen Datenschutz Vorfall möchte man nicht in der Zeitung lesen. Auf gar keinen Fall. Das habe ich in der Vergangenheit häufiger erlebt, dass da sehr viele Menschen gleichzeitig sehr viel Druck gemacht wird und das natürlich voll auf die IT durchschlägt.

Teilweise weil die Projektmanager selber nicht damit umzugehen wissen, selber so ein bisschen keine Handhabe haben, nichts machen können und die IT Fachkräfte angucken nach dem Motto okay, was machen wir denn jetzt? Ihr müsst das doch wissen. So ja doch schon. Ich kann mich an eine Situation erinnern, da gab es ein Problem. Ein Datenschutz vorfall der lief über zwei Wochen oder die Probleme Erhebung lief über zwei Wochen. Das betroffene System wurde dann abgeschaltet. Aber die Lösung hat halt längere Zeit in Anspruch genommen und das war alles andere als schön. Also das war richtig intensiv, auch sowohl von der Kommunikation als auch von der Lösung. Nach DSGVO Richtlinie kann ein Unternehmen bis zu x Prozent des Umsatzes an Strafe zahlen müssen. Ich weiß es jetzt gerade nicht, aber das ist schon eine doch mehr als empfindliche Strafe. Und da entsteht dann diese Drucksituation.

Gerade mit Datenschutz. Also wo du selber jetzt nicht für verantwortlich bist, wenn du von außen keine Ahnung gehabt wirst oder ein Vorfall hat, wenn also da muss man sich jetzt nicht groß, glaube ich, mit diesem. So viel Angst zu haben, so wenig ist aber nicht schnell genug reagieren. Dann steht die Keule da und mein Unternehmen muss die 70 Millionen € zahlen. Das muss man schon ein bisschen differenziert betrachten.

Ich glaube, die Schiedsstelle, die diese Strafen auch ausspricht, die will natürlich einfach sehen, dass du dich schnellstmöglich darum kümmerst, dass diese Lücke abgedichtet wird. Und die steht halt nicht rum und freut sich über jeden Vorfall, um direkt die maximale Sanktion da rein zu drücken. Es soll ein scharfes Schwert sein, damit die Leute, damit die betroffenen Unternehmen schnell diese Lücken abdichten und nicht sagen Ach ja, gut, machen wir nächste Woche oder so was. Weil das natürlich auch katastrophale Folgen haben kann. Man erinnere sich an die ganzen Verschlüsselungen Trojaner oder Erpressungsversuch Trojaner. Klar, das muss natürlich abgedichtet werden und natürlich so schnell wie möglich. Und ich glaube, diese hohen Strafen dienen dazu, schnellstmöglich die Priorität auf das Schließen dieser Sicherheitslücke zu fokussieren. Aber man kann eigentlich generell sagen Bei Druck und Kostendruck ist so ein System. Ausfall ist eine Sicherheitslücke ist oder ein Zeitdruck ist erst mal einen kühlen Kopf bewahren und gucken. Bei Zeitdruck kann ich irgendwas nicht essenzielles weglassen und bei System Ausfällen oder Sicherheitslücken gucken. Okay, wie ist jetzt der schnellste Weg um dieses Problem zu lösen?

Und was muss ich tun, um das dann einfach konzentriert umzusetzen? Wenn unsere Zuhörer Fragen haben, sendet uns gerne eine Email an Podcast Skillbyte Wir freuen uns immer über Bewertung und Weiterempfehlung unseres Podcasts an Freunde und Kollegen. Falls ihr den Podcast noch nicht abonniert habt, lasst gerne ein Abo da. Des Weiteren könnt ihr gerne auf Skillbyte Slash Blog vorbeischauen. Vielen Dank für die Session heute.

Sehr gerne. Hat wieder Spaß gemacht. Bis zum nächsten Mal.

Freue mich bis zum nächsten Mal.