In Folge 15 geht um Troubleshooting und Agilität im Projektmanagement. Dazu spreche ich mit Troubleshooter a.D. Maik Pfingsten.
Podcast: Play in new window | Download (Duration: 28:38 — 23.8MB)
CIO Podcast abonnieren: Apple Podcasts | Spotify | Amazon Music | Android | RSS
Folgende Aspekte werden in der Podcast-Folge besprochen:
- Gründe für das Scheitern von Projekten und den Einsatz von Troubleshootern [00:01:00]
- Die ersten Schritte eines Troubleshooters im Projektmanagement [00:03:00]
- Scrum und Kanban in IT-Projekten einsetzen [00:10:30]
- Rahmenbedingungen, die IT-Manager für den Einsatz agiler Vorgehensweisen schaffen sollten [00:17:20]
- Unter Zeitdruck abgestimmte Lastenhefte erstellen [00:20:00]
- Ein Tipp an CIOs, IT-Manager und IT-Führungskräfte [00:24:50]
Mike Pfingsten ist Diplomingenieur für Mechatronik und hat über zehn Jahre als externer Troubleshooter Unternehmen dabei unterstützt, ihre internationalen Entwicklungsprojekte zu retten. Und heute ist der Keynote Speaker, Autor und Mentor und gibt in diesem Bereich sein Wissen zum Thema Projektmanagement, Systems Engineering und Leadership weiter.
Weiterhin ist er auch ein Podcaster Kollege und betreibt zwei Podcasts, einen für Systemingenieure. Das ist der „Zukunftsarchitekten Podcast“ und einen für Unternehmer und Game-Changer und der Podcast „Auf das Leben“. Weiterhin stellt er sein Wissen auch in Form von Online-Bibliotheken zur Verfügung. Diese Bibliotheken findet man unter lastenefterstellen.de.
Ja, freuen Sie sich mit mir auf ein spannendes Interview zum Thema Projektmanagement und Agilität und was wir im Projektmanagement der IT verbessern können und wie wir mehr Agilität in die Abläufe bekommen. Viel Spaß. Wir freuen uns auf Ihr Feedback!
Jetzt wünsche ich Ihnen einen guten Rutsch in ein glückliches, gesundes und erfolgreiches neues Jahr 2017. Bis dahin. Auf Wiederhören.
Weiterführende Links
- „Zukunftsarchitekten“ Podcast
- „Auf das Leben“ Podcast
- Agile Lastenhefte erstellen
- Online Bibliothek von Maik Pfingsten
- XING Profil von Maik Pfingsten
- Folgen Sie Maik Pfingsten auf Twitter
Transkript des Interviews zum Nachlesen
-
Petra Koch:
In Ihrer Erfahrung aus über 10 Jahren als Troubleshooter und Systemingenieur in der Automobilentwicklung haben Sie sicherlich so einiges gesehen. Was sind die häufigsten Gründe, warum Projekte, ich sage mal, vor die Wand fahren und wann dann ein Trouble Shooter benötigt wird?
00:01:59-5
-
Maik Pfingsten:
Also deutlich wird das im Grunde an dem Punkt, wenn ein Kollege aus dem Projekt versucht seine Stunden aufzuschreiben in SAP und dann kommt aus dem Sekretariat die Rückantwort: Die SAP Nummer ist voll. Das war oft so der Moment, wo ich als Troubleshooter dann gerufen wurde. Das ist aber oft nur das Symptom, das ist nicht die Ursache.
Die Ursache liegt häufig viel, viel tiefer, viel weiter vorne verborgen im Projekt. Da sind oftmals handwerkliche Fehler gemacht worden, ist völlige Unklarheit, was die Anforderung, die Lasten sind an das ganze Projekt, was da eigentlich entwickelt werden sollte. Oftmals natürlich auch viel Macht- und Ränkespiele. Also da gibt es verschiedene Gründe, aber es sind so die ganz typischen Elemente, die dabei eine Rolle spielen.
00:02:45-6
-
Petra Koch:
Ja vor allen Dingen, wenn es ja auch nicht vorher auffällt. Wenn man dann schon die SAP-Nummer vollgespielt hat sozusagen (lacht) und Ihr Budget und dann, wenn es gar nicht mehr geht, die Sekretärin sagt, übrigens
00:02:55-9
-
Maik Pfingsten:
Genau, genau. Das ist so der der Moment, wo dann allen plötzlich klar wird, so wir haben hier glaube ich gerade ein Problem. Wir haben kein Geld, aber noch eine ganze Menge Zeit über und jetzt muss irgendwas passieren.
00:03:08-8
-
Petra Koch:
Ja. Also im Projektmanagement sollte man das ja irgendwie schon mal früher entdecken, ne?
00:03:12-8
-
Maik Pfingsten:
(lacht) Meistens, ja die Indikatoren, also gerade, wenn man so ein bisschen Risikomanagement betreibt, die Indikatoren sind oftmals schon über Monate, manchmal schon teilweise über ein Jahr, anderthalb Jahre vorher sichtbar gewesen. Sie hat nur keiner, also keiner hat es wahrgenommen.
00:03:24-4
-
Petra Koch:
Okay, wird dann nicht weiter hochgespielt. Und was ist das Erste, was Sie machen, wenn sie dann als Troubeshooter in so ein Projekt kommen, was eigentlich schon irgendwie aus dem Budget rausgelaufen ist oder eben andere Schwierigkeiten hat?
00:03:35-9
-
Maik Pfingsten:
Na gut, die Situation ist gerade in meinem Kontext, als ich noch aktiver Troubleshooter war, habe ja über 10 Jahre operativ Projekte gerettet, in verschiedensten Branchen, Unternehmen und Projekten. Die Situation ist, dass dann erst mal innerhalb des Unternehmens versucht wird, okay wie können wir jetzt mit dieser Situation umgehen? Und oftmals war es dann so, dass Entscheider aus dem mittleren und Top-Management irgendwoher meinen Namen kannte, so viel Troubleshooter gibt es nicht und die Automobilbranche ist jetzt auch nicht so riesengroß. Also zumindest die, die in Entwicklung sind, also in Produktentwicklung, dass dann irgendwann der Anruf bei mir kam und sagte: Ja, Herr Pfingsten wir haben da ein Problem, können Sie vielleicht uns da mal irgendwie helfen?
Und ich habe über die Jahre für mich selber einen 5-stufigen oder 5-phasigen Prozess entwickelt. Dass ich den entwickelt habe, habe ich auch viel später erst wahrgenommen, als ich das mal irgendwann mir selber angeschaut hatte.
Aber im Grunde basierte das auf der ersten Phase, das Team wiederaufbauen. Also ich komme ja in solche Projekte dann rein und diese Teams sind oft komplett durchgenudelt. Also die haben über Wochen durchgearbeitet, die haben im Grunde einen Schlafsack direkt neben ihrem Arbeitsplatz. Die haben nur noch von Pizza gelebt, die haben seit Wochen ihre private Zeit nicht mehr so einsetzen können. Ob das jetzt Familie ist, Hobby ist, was auch immer. Das ist meistens ein Team, was ziemlich durchgerockt ist und dieses Team erstmal wieder aufbauen wird in den ersten 2 Wochen war primär meine Aufgabe zu gucken, okay, wer zieht überhaupt noch mit, wer hat die Kraft überhaupt noch mitzuziehen?
Wer ist überhaupt noch in der Lage, mit der Energie in der Regel 6 Monate, die dann jetzt vor uns liegen, gemeinsam zu ziehen und dann auch zu gucken, okay, die, die jetzt nicht können oder nicht wollen auch entsprechend in Abstimmung mit den Führungskräften innerhalb des Unternehmens aus diesem Projekt rauszunehmen. Weil ich bin ja zwar in einer Führungsrolle, ich hatte dann am Ende große internationale Teams mit über 150 Leuten geführt, aber ich bin ja nicht in der eigentlichen Linie eine Organisation. Das ist ja auch nicht mein Job und deswegen bin ich auch nicht da. Es ist wie ein Feuerwehr-Männchen, der dort rein springt und es auf Zeit wieder gerade bringt.
Und dieser Team-Schritt ist wesentlich, weil mit dieser ersten Geschichte kommt oftmals was dazu, dass ich dann dieses Team auch abschirme nach oben zum Top-Management. Diese Projekte sind meistens schon seit Wochen, teilweise über Monate knallrot im Reporting. Auch ins Top-Management rein und das heißt, häufig ist es so, dass dann irgendein Top-Geschäftsführer, Vorsitzender des Vorstands irgendwo dann an den Kunden reporten durfte, okay wir haben wieder rot, wir haben wieder ein Problem und diese Personen haben natürlich ein eigenes Interesse aus erster Hand zu verstehen, okay, wo steht das Projekt? Das heißt, sie kommen in dieses Team rein und fragen dann: Ja, wie sieht es denn aus? Und dann stehen die bei irgendeinem Software-Ingenieur am Schreibtisch und fragen: Wie sieht es denn aus?
Also erst mal muss man sich das im krassen Level vorstellen. Top Manager, ganz viele Federn auf dem Haupt, stehen neben einem Integrationsspezialisten im Embedded Software Umfeld, das ist so ein krasser Level, die haben sich vorher wahrscheinlich noch in einer Betriebsratssitzung mal irgendwann gesehen und dann auch nur sehr unidirektional (lachen beide) und dann entweder sagen die gar nichts, weil sie sich überhaupt nicht trauen, was zu sagen oder wenn sie was sagen, dann ist es meist sowas so: Ja, irgendwie mein Debugger funktioniert gerade nicht. Ich habe die Installation nicht hingekriegt. Und was hört der Top-Manager so? Oh, das Projekt, das ist wieder alles ganz
00:06:55-7
-
Petra Koch:
Geht schon wieder nicht.
00:06:56-4
-
Maik Pfingsten:
So und das heißt, mein Job war es da, einen Schirm aufzuspannen und auch dem Top-Management beizubringen, es wird nur noch über mich kommuniziert. Weil das bringt am Ende gar nichts, wenn so ein Top-Manager neben so einem Superspezialisten im Projekt steht und versucht irgendwie rauszukriegen, was ist da eigentlich jetzt gerade Phase in einem Projekt?
00:07:13-3
-
Petra Koch:
Ja, ist eine völlig andere Sprache dann auch?
00:07:15-3
-
Maik Pfingsten:
Ja natürlich, auch eine andere Sicht, also auch ich meine am Ende muss uns das klar sein, gerade in solchen Projekten hat das viel mit Macht und Machtspielen zu tun. Da werden an einigen Stühlen im Hintergrund rumgesägt und dementsprechend ist natürlich so ein Manager im mittleren oder Top Level mit einer völlig anderen Sicht aufs gleiche Thema unterwegs, weil es unter Umständen um seine Karriere geht und seine Macht, seine Fähigkeit, seine Gestaltungsmöglichkeiten. Während es bei den, ich sag mal Teamkollegen, der Teamkollegin halt mehr darum geht, seine handwerkliche Tätigkeit mit viel Leidenschaft umzusetzen und oftmals sind das ja auch Menschen, die gar nicht so karriere-ambitioniert sind, weil sie sich ganz anders ausspielen im Leben. Ja und das spielt dann oft mit rein.
Also das ist so der 1. Teil. Der 1. wesentliche Teil und dann geht, muss halt los in den 2. Teil, wo wir erst einmal überhaupt die Lasten geklärt haben. Also was ist überhaupt, was sind die Lasten an das, was da hinten rauskommen soll? Das ist oftmals überhaupt nicht klar. Entweder haben wir gar keine Lastenhefte vom Kunden, das habe ich auch alles schon erlebt. Oder wir haben, das nervte, die wurden mir dann in Paletten an den Schreibtisch gefahren, so dass ich erstmal 6 Monate damit beschäftigt gewesen wäre die zu lesen und wahrscheinlich wären 70 Prozent eben Müll gewesen.
Also es war ein etwas unsinniges Ergebnis, was ich da dann bekommen habe und habe dann innerhalb von zwei Wochen ein sauberes Lasten erstellt mit Freigabe. Und das waren so die ersten, die zweiten 2 Wochen. Damit habe ich im Grunde die Basis bestritten, um dann in Strategie zu gehen.
Also jetzt muss ich hingehen und kläre: Was ist denn die Strategie? Wie können wir denn vorgehen in den 6 Monaten? Was ist die Release-Planung? Wann werden wir noch was an Ergebnissen liefern? Was können wir überhaupt liefern? Was werden wir gar nicht mehr liefern in den 6 Monaten? Was gibt es vielleicht später mal, wenn ich weg bin in einem Update von dem Produkt oder so dann geliefert? Und das muss natürlich auch noch durchverhandelt werden, also dann natürlich mit dem Unternehmen, wo ich im Projekt drin aktiv bin, aber natürlich auch mit Kunden, weil der will ja wissen, was er auch kriegt.
Das sind so die ersten zweimal 3 Wochen, äh dreimal 2 Wochen, so rum und dann geht’s ins Operative. Das ist halt ein klassisches Projektmanagement. Da geht’s ans Umsetzen, dass wir dann wirklich nach 6 Monaten aus dem Werkstor kommen.
00:09:18-3
-
Petra Koch:
Okay, also das ist dann quasi Phase 3, 4, 5 ist dann operativ?
00:09:22-7
-
Maik Pfingsten:
Ja, Phase 3 ist dann die Strategie, also Phase 1 ist Team, Phase 2 sind Lasten und Phase 3 Strategie, Phase 4 ist das Operative und dann die abschließende Phase können wir dann gleich auch nochmal im Detail gerne beleuchten, ist dann eine Phase, wo wird das ganze Projekt abschließen.
Zumindest für mich ist diese Phase ganz wichtig Ich habe von Anfang an das Ziel, dass ich mich unnötig mache. Dass ich nicht mehr gebraucht werde, weil ich muss als Troubleshooter aus dieser hochgradig intensiven Rolle ganz schnell wieder raus. Sonst gehe ich daran kaputt. Das heißt, mein Ziel war es immer nach 6 spätestens nach 12 Monaten wieder raus zu sein aus diesem Projekt und damit quasi von Tag 1 auch die Basis zu legen. Jetzt haben wir oft aber das Problem, so ein Projekt läuft jetzt 6 Monate. Man kommt zum Ergebnis. Das Team hat funktioniert, es hat alles Spaß gemacht, wir haben was rausgebracht, was am Ende dann doch alle glücklich irgendwie gemacht hat. Und dieses Team ist aufeinander eingespielt.
Das heißt, nicht nur, dass ich gehe, sondern dieses Team weiß, jetzt ist das Projekt vorbei und wir werden in alle Winde, Windrichtungen verstreut in neue Projekte und da haben die oft keine Lust drauf. Finden dann ganz viele tolle Ideen, warum das Projekt noch weiter existieren muss. Und das ist Phase 5, also dann wirklich sauber das Projekt abschließen.
00:10:25-4
-
Petra Koch:
Mhm (bejahend) okay. Dass dann die Leute auch wirklich vergnügt und ruhig dann auch in neue Themen können.
00:10:30-5
-
Maik Pfingsten:
Genau, genau.
00:10:31-0
-
Petra Koch:
Mhm (bejahend) sehr gut. Klasse. Jetzt ist das ja was Sie angesprochen haben, gerade schon, hört sich so ziemlich nach Wasserfall Vorgehen auch an. Also so teilweise zumindest. Es ist schon relativ strukturiert, jetzt ist ja in vielen Themen, gerade in der IT, wenn wir uns IT-Organisationen angucken, ich weiß nicht, wahrscheinlich auch im Systemingenieur-Bereich sind ja so Themen wie Scrum und Kanban aktuell.
Können Sie Scrum und Kanban ganz kurz erläutern für die IT-Manager und wonach würden Sie auswählen, welche der Methoden man denn auch einsetzen kann in solchen Projekten?
00:11:04-0
-
Maik Pfingsten:
Also ich bin schon seit 2005 in der agilen Szene mit unterwegs. Ich habe hier in Köln eine ziemlich agile Szene und habe da auch einige Koryphäen schon sehr früh kennengelernt und auch mit denen nicht darauf. Weil ich komme natürlich aus so einem klassischen Ingenieur-Projektmanagement oder wie es halt so neudeutsch heißt, Vintage Projektmanagement, also klassisch halt. Ja, das ist nicht Wasserfall, also das nicht falsch verstehen, Wasserfall wird oftmals immer so herangezogen.
Wir haben nie Wasserfall entwickelt. Wir haben ein V-Modell entwickelt und diese Iterationen sind auch nicht wahnsinnig viel länger als bei einem Scrum Sprint. Aber das Interessante ist, es sind halt einfach verschiedene, ja ich sage mal Werkzeuge, die wir nutzen können und innerhalb dieser Werkzeugkisten auch wieder Methoden, die wir einsetzen können und ich bin extrem pragmatisch veranlagt.
Das heißt, ich war nie irgendwie ein dogmatischer Verfechter von „Wir müssen aber alles nach klassisch Vintage machen“ oder alles nach „klassisch agil“, sondern ich nehme mir das Werkzeug, was am besten auf mein Problem passt und dementsprechend, man sieht das an dieser Ausrichtung auf der obersten Ebene, reden wir 2 Wochen, 2 Wochen, 2 Wochen? Dann so Pi mal Daumen 4 1/2 Monate und dann ungefähr nochmal 4 Wochen. Das heißt, ich sprinte, gehe dann in eine, auf einer Metaebene auf eine längere konstante Phase, weil ich innerhalb dieser Phase wieder sehr stark iteriere, also ich habe da auch schon Sprints.
Ich mache zwar ein Release-Planung, wo ich sage, wir machen jetzt in den nächsten 8 Wochen den B-Muster-Stand und dann noch mal in 6 Wochen den C-Muster-Stand oder sowas, aber innerhalb dieser Stände gehe ich hin und mache wieder Sprints von 2 Wochen. Also ich mische das schon, wobei ich das jetzt niemals irgendwie dogmatisch belege mit, das ist Scrum, das ist klassisch V-Modell oder sowas. Wichtig ist, dass die Ergebnisse da sind.
Vielleicht nochmal zur Erläuterung der beiden Begriffe. Das Scrum ist ein Projektmanagement Framework, ein Denkansatz, eine Denkschule im Grunde, die gerade sehr software-lastigen Projekten zugutekommt. Wo wir die Situation haben, wir haben von Haus aus Systemingenieure. Das heißt, ich komme aus der Mechatronik, die Kollegen aus der Konstruktion und die Kollegen aus der Hardware-Entwicklung, die haben es einfach, das Ergebnis können die im wahrsten Sinne des Wortes hinterher anpacken. Sie begreifen.
00:13:07-1
-
Petra Koch:
Das geht mit einer Software nicht.
00:13:08-1
-
Maik Pfingsten:
Genau, das geht mit Software nicht. Das ist gerade für die Kollegen aus dem Maschinenbau Kontext war das immer so ein bisschen schwierig. Ich komme ja aus einem Embedded Software Kontext. Wenn ich dann versucht habe denen zu erklären: Ja okay das ist die Architektur. Ja wie sieht das denn genau aus? Macht mal so einen Code Editor auf und dann sieht er da nur ganz viele Codezeilen und sagt so: Ja, aber das ist ja etwas Anderes als das, was du mir auf das Whiteboard malst. Und wie verhält sich das?
Und das ist oftmals der Punkt, wo dann solche agilen Ansätze in solchen Kontexten wie eben Embedded Software, IT, Web und so weiter viel besser funktionieren, weil wir da einfach viel schneller die Möglichkeit haben, zu dem Ergebnis mal eine Aussage zu machen. Denn wir haben einfach bei Software das Problem, sie bricht nicht. Und das ist halt auch das. Also bei Mechanik ist es einfach. Ja ich kann irgendwann ein Pedal mit so viel Kraft belegen, dass das Pedal durchbricht, beim Flugzeug. Das haben wir bei Software nicht.
Software bricht nicht, das heißt, wenn wir Fehler entdecken, wissen wir gar nicht oft wie schwerwiegend diese Fehler sein können und sie dann einzugrenzen und auch zu finden und wirklich den Fehler zu finden und nicht nur das Symptom zu heilen, ist bei Software viel, viel schwieriger als zum Beispiel in der Konstruktion oder Elektronik.
00:14:10-0
-
Petra Koch:
Ja gerade, wenn es um sicherheitsrelevante Sachen dann geht.
00:14:12-6
-
Maik Pfingsten:
Genau. Und der andere Begriff Kanban, Kanban eine Lean-Methode. Das ist eine, kommt ursprünglich, ich glaube 1947 hat das der Toyoda entwickelt für seine Produktion. Ist eine ganz witzige historische Geschichte. Das heißt, das ist eine Methodik, die gerade in der Automobilproduktion urlange bekannt ist. Ist dann irgendwann auch so über die anderen Maschinenbau-Branchen in der Fertigung gewandert.
Also jeder hat Kanban gelernt, auch schon in den 80er, 90er Jahren, das war ein Standard-Hilfsmittel. Und in den 90er Anfang der 2000er sind Kollegen aus dieser agilen Szene irgendwann drüber gestolpert und haben gesagt: Na ja, eigentlich kann man diesen Ansatz, den in der Produktion ja durchaus bekannten Vorgehensweise, Engpass basierten Ansatz übertragen in eine Geistesleistungstätigkeit, also sprich zum Beispiel Entwicklungsprojekte. Und sind dann hingegangen und haben sich da Gedanken macht, man muss auch vom Pull zum Push umstellen, das ist so die große Änderung, aber ansonsten ist vieles gleich.
00:15:11-6
-
Petra Koch:
Und was heißt das konkret, wenn man jetzt sagt, von Pull zu Push umstellen?
00:15:14-2
-
Maik Pfingsten:
Also ich, wenn ich in der Fertigung Kanban mache, dann pull ich. Das heißt, ich ziehe mir vom vorherigen Arbeitsplatz das nächste Ergebnis rüber. Während ich bei dem Ansatz, den wir ich sage mal im Geistesleistungsumfeld machen, wir pushen quasi das Ergebnis zum nächsten rüber und merken, jetzt ist ein Engpass, ich kann nicht weiter pushen. Das ist so der eigentliche Unterschied. Da steckt dann im Grunde einfach nur ein Umgang mit den Arbeitspaketen dahinter.
00:15:39-7
-
Petra Koch:
Dass man das Modell einfach überträgt dann?
00:15:41-8
-
Maik Pfingsten:
Genau. Faszinierend war das, ich hatte die Situation 2010. Jetzt komme ich da teuer bezahlter Troubleshooter in solche Entwicklungsprojekte, das heißt, da sind natürlich dann Manager und die wollen auch immer regelmäßig wissen, was dann jetzt los ist in dem Projekt und die kommen dann an den Arbeitsplatz, wo der Herr Pfingsten dann sitzt und der ist ja nie da. Weil Kommunikation ist eines der Hauptbestandteile meiner Tätigkeit, das heißt, ich bin viel unterwegs in Meetings, in Abstimmung mit Leuten, im Test, im Fahrzeug, beim Kunden und so weiter.
Das heißt, der hat immer das Gefühl, der Pfingsten ist nicht da und dann passiert irgendwie auch nichts. Was läuft da gerade? Und dementsprechend habe ich irgendwann den Punkt gehabt, wo ich sage: Ich muss jetzt irgendwie visualisieren das, was im Projekt passiert. Und bin über Kanban gestolpert als Ansatz, also den Kanban der Kollegen aus dem agilen Kontext und dachte, ach das ist ja ganz nett. Da kann ich jetzt Zettelchen durch die Gegend schieben und dann kann der, ein Scharlatan aus dem Top-Management, okay da waren ja Zettelchen, da muss ja auch was passieren und genau das hat funktioniert.
Und dann habe ich festgestellt, hmm das ist irgendwie mehr. Und habe dann angefangen darüber mein Team zu steuern und habe die Möglichkeit, dann plötzlich auch zu sehen, okay wo haben wir Engpässe in der Arbeitsstruktur, in den Abläufen, die wir haben? Habe das 2010 wie gesagt noch, das war noch mit einem Onsite-Team, also ein Team, was, wo ich, wo wir zusammensaßen, wir hatten dann einfach ganz simpel aus der Konstruktion und so zwei Bahnen von den Konstrukteuren aus deren Plottern gezogen und auf eine Wand geklebt und haben dann Striche draufgemacht, mit Postits und so weiter.
Ich habe es dann immer weiterentwickelt, ich habe darüber hinterher ein internationales Team gesteuert. Wir haben das Ganze natürlich dann webbasiert gemacht, weil denen kann ich jetzt nicht wie ein Papier vor die Kamera kleben. (lachen) Das funktioniert nicht so ganz. Aber es hat super funktioniert. Und das war wirklich genial. Also das ist eine Art und Weise, wie ich heute wirklich Arbeitsorganisation betreiben kann.
00:17:21-1
-
Petra Koch:
Klasse. Ja ich habe es in den IT-Projekten jetzt auch schon erlebt. Was ich andersherum aber da häufig feststelle ist, dass die Leute sagen: Super, wir machen jetzt Scrum und Kanban und alle haben so das Gefühl, es ist dann nur noch agil und man macht irgendwie, ja man dokumentiert irgendwie nichts mehr oder man hat eben halt gewisse Regelwerke auch nicht mehr. Also vielleicht an der Stelle mal: Was würden Sie da den IT-Manager mitgeben? Welche Rahmenbedingungen sollten sie schaffen, wenn sie so agil arbeiten?
00:17:45-4
-
Maik Pfingsten:
Also agiles Arbeiten oder überhaupt dieser ganze agile Ansatz basiert ja sehr stark auf dem Punkt, dass ich Verantwortung in das Team hineingebe. Das kam mir natürlich sehr gelegen als Troubleshooter, weil ich
00:17:57-9
-
Petra Koch:
Alles alleine kriegt man dann auch nicht hin.
00:17:59-5
-
Maik Pfingsten:
Alles alleine kriege ich ja eh nicht hin. Außerdem will ich ja nach 6 Monaten aus diesem Projekt wieder heraus. Ich will mich ja überflüssig machen. Also war es ganz wichtig, dass ich all meine ganze Verantwortung, Tätigkeit den Leuten übergebe, sie befähige, ermögliche also Leadership auch lebe, dass sie selber in der Lage sind, diese Sachen umzusetzen. Das heißt, das war für mich irgendwie natürlich, der Match zwischen agilen Methoden und dem was ich sowieso als Vintage Projektmanager, sage jetzt mal, machen wollte.
Und das heißt, das ist das, was ich auch so bei den Managern im IT gerne mitgebe, ist eben dieses Bewusstsein, es verändert sich jetzt auch meine Art der Führung, wenn ich in solche Richtungen gehe, in diese Denkschulen reingehe, weil ich viel stärker auf Vertrauensbasis arbeite, ich muss Verantwortung an die Teams abgeben, die Teams entscheiden selbstständig. Das bedeutet aber auch, sie brauchen einen Rahmen, um diese Entscheidung gut zu fundieren und dann kommt wieder meine Rolle ins Spiel.
Also es ist weg von diesem Order Mufti, klassischem Management, eben hin, ich sag mal, ich habe einen Kollegen, der war Elite-Offizier bei der Bundeswehr und mit dem habe ich mich mal ausgetauscht wie die Führung gemacht haben, wie die Führung gelernt haben. Und die haben ein Konzept, Führung durch Auftrag. Das bedeutet, wenn, das ist einzigartig in der deutschen Bundeswehr, das hat keine andere Armee so installiert. Wenn die Offiziere in der Bundeswehr ein Team losschicken für den Auftrag, dann kriegt dieses Team den Auftrag, kriegt die Rahmenbedingung, kriegt alle Informationen, die sie brauchen, kriegt sein Handwerkszeug, was sie brauchen, wird ausgestattet und ist dann operativ aber eigenständig.
00:19:27-3
-
Petra Koch:
Ja. Ein wichtiger Punkt finde ich aber auch, kriegt alle Informationen. Das ist ja häufig,
00:19:31-1
-
Maik Pfingsten:
Genau.
00:19:31-0
-
Petra Koch:
Wenn man das in den Projekten so sieht, dann tröpfeln die Informationen so nach und nach ein.
00:19:36-3
-
Maik Pfingsten:
Genau. Und dann kann dieses Team voll autark operieren und sogar und das ist das Spannende, im Zweifel auch den Auftrag abbrechen, wenn das begründet ist, ohne, dass sie disziplinarische Probleme bekommen daraus. Das ist lustiger weise in keiner anderen Armee so.
00:19:52-8
-
Petra Koch:
Das ist sehr interessant. Und das ist aber für die agile Vorgehensweise ja dann echt auch eine wesentliche Veränderung im Führungsverhalten.
00:19:59-1
-
Maik Pfingsten:
Ja. Absolut, absolut.
00:20:01-3
-
Petra Koch:
Sehr gut. Jetzt vielleicht ein Punkt. Das haben wir eben auch schon mal ganz am Anfang, in Phase 2 war das glaube ich, dass man mal guckt, welche Lasten hat der Kunde? Da haben Sie ja auch eine spezielle Lastenheft-Methode sozusagen entwickelt, wie man da relativ schnell, ich glaube in 2 Wochen sogar, zu einem abgenommen, freigegebenen Lastenheft kommt. Was steckt da dahinter?
00:20:21-2
-
Maik Pfingsten:
Also dahintersteckt, also zwei Gedankenansätze. Das Eine, ich brauche klare Lasten, ich brauche Klarheit, was da am Ende entwickelt werden soll, weil ohne das kann ich nicht ernsthaft irgendwelche strategischen Entscheidungen überhaupt für das Projekt entwerfen.
Das Zweite ist, ich brauche diese Lasten mit einer Unterschrift und wer schon mal versucht hat unter egal welcher Art von Spezifikation eine Unterschrift darunter zu bekommen, der diese Situation erlebt, dass dann plötzlich ganze Flure leer sind und so stachelige Büsche so da durchrollen.
00:20:52-0
-
Petra Koch:
(lachen) Da findet sich keiner mehr, der gerade noch einen Stift in der Hand hat.
00:20:54-9
-
Maik Pfingsten:
Genau. Und so brauchte ich halt einfach eine Vorgehensweise, wo ich A) sehr schnell, auf den Punkt, ein freigegebenes Lastenheft bekomme ohne Unterschrift und das ist das, was ich dann relativ früh aufgebaut habe, wo ich wirklich über ganz einfache, auch sehr agil aufgebaute Vorgehensweise, 2 Wochen, wir sind wieder im Sprint Gedanken, eben dadurch fahre und am Ende wirklich mit einem freigegebenen Lastenheft inklusive Dokumentation, dass ich sogar prozesssicher bin, rauskomme und das ist Teil meiner Freigabe. Also da muss keiner was unterschreiben. Das ist das Spannende daran.
Und ich nenne das, also es hat in verschiedenen Kontexten bei mir verschiedene Namen. Einen Namen, den ich gerne benutze, ist eben agile Lastenhefte, weil das ist das Interessante, wenn man sich mit dem ganzen agilen Manifest mal beschäftigt, die meisten lesen ja immer nur die 4 agilen Regeln. Wir haben aber, wenn man weiter runter scrollt, noch die Prinzipien. Das ist das, was die Wenigsten lesen. Und wenn ich dauernd das Software gegen das Wort Lastenheft ersetze, erfülle ich alle Prinzipien des agilen Manifests. Deswegen nenne ich es gerne agile Lastenhefte.
00:21:54-8
-
Petra Koch:
Okay. Ganz kurz vielleicht, was sind da die wesentlichen Prinzipien für die, die sie jetzt noch nicht kennen?
00:21:59-7
-
Maik Pfingsten:
Also ich habe das aufgeteilt, auch wieder lustiger weise in 5 Phasen, aber jetzt diesmal in diesen 2 Wochen Block, wo ich wirklich in jeder Phase nur eine klare Tätigkeit tue. Also als Systemingenieur sind Anforderungsspezifikationen für mich nichts Neues, das ist Teil meines Handwerks. Ich bin nur hingegangen und habe gesagt: Okay, wenn wir dieses, also klassischen Spezifikation schreiben, wir so zwischen 3 und 6 Monaten, ohne Goldrahmen, also handwerklich sauber.
Genau, so was tue ich da? Ich erfasse erstmal alle Anforderungen. Dann fange ich an erst einmal das, was ich habe, zu sortieren. Dann finde ich Lücken, die muss ich füllen. Dann muss ich das Ganze prüfen, also gucken, ob das, was ich da eigentlich zusammengeklimpert habe, überhaupt richtig ist. Und dann muss ich das ganze Ding freigeben.
Das ist der klassische Ansatz, nur ich mache es im klassischen Ansatz, vermische ich diese verschiedenen Tätigkeiten. Ich erfasse mal Sachen, dann sortiere ich die, dann fülle ich mal ein bisschen was, dann erfasse ich neue Sachen, dann prüfe ich schon mal ein paar Sachen, dann erfasse ich wieder was dann, dann fülle ich wieder was. Und irgendwann komme ich zu der Freigabe und dann diskutieren wir alle tagelang über den Inhalt. Und ich bin eben genau, genau diese Tätigkeit, die ich als Systemingenieur mache bei einer Spezifikation, einfach wie so eine Perlenkette hintereinander aufgefüllt.
Das heißt, es gibt einen 1. Tag. Also wir starten quasi in der 1. Woche montags als Beispiel jetzt mal und machen montags nur Erfassen und diese Phase ist montags zu Ende. Alles, was wir erfasst haben, haben wir erfasst, was wir da nicht erfasst haben, wird auch nicht mehr ins Lastenheft kommen. Dann Phase 2 ist Sortieren. Das sind 2 Tage, also Dienstag, Mittwoch. Da sortieren wir das, was wir erfasst haben, in das Template, in die Schablonen rein. Dann finden wir nämlich eine, am Mittwochabend sehen wir dann plötzlich die ganzen Lücken. Das heißt, Donnerstag, Freitag in der 1. Woche ist dafür reserviert, diese Lücken zu füllen, so dass ich quasi Freitagabend technisch gesehen mit einem vollständigen Lastenheft rausgehe.
00:23:42-0
-
Petra Koch:
Ja okay. Ist ja Wahnsinn, in einer Woche. Ja.
00:23:44-7
-
Maik Pfingsten:
Genau. Was aber noch nicht vom Reifegrad perfekt ist. Und jetzt fängt die 2. Woche an und da gehe ich jetzt montags, dienstags, mittwochs hin und mache sehr iterative Peer-Reviews. Also das kommt aus der Wissenschaft. Ich gebe einfach jetzt Kollegen, gehe zu ihm, gebe ich meine Unterlagen und sage, können Sie mal drüber schauen, geben Sie mir ganz schnell Feedback ohne Dokumentation, einfach mit dem Stift auf dem Papier drum rum gemalt oder so.
Alles cool und mache diese Iteration, das heißt, ich mache durch diese Peer-Reviews und diese kurzen Zyklen habe ich den Effekt, dass ich zum einen den Reifegrad sehr schnell sehr hoch hebe. Zum anderen haben alle diese Dokumente schon mehrmals gelesen oder zumindest die Teile, die für sie relevant sind, sodass ich dann am Donnerstag in einem großen Freigabe Workshop gehe, dort das ganze Dokument mit allen gemeinsam nochmal durchlese. In der Regel habe ich aber keine Diskussion.
Alle haben das Dokument schon mal gelesen, aber es fallen jetzt noch viele Kleinigkeiten auf. Das ist normal, das dokumentiere ich dann auch alles. Und am Freitag pflege ich diese Sachen ein und protokolliere, dass ich sie alle abgestellt habe und habe dann quasi am Freitag der 2. Woche ein Lastenheft mit Freigabestand inklusive Review-Protokoll, also prozesssicher.
00:24:46-7
-
Petra Koch:
Okay. Ja klasse. Gut. Eine Frage vielleicht noch zum Abschluss.
00:24:51-5
-
Maik Pfingsten:
Gerne.
00:24:52-0
-
Petra Koch:
Wenn Sie einem CIO beziehungsweise einem IT-Manager einen einzigen Tipp geben könnten, dass eben ein Projektmanagement gut funktioniert und vielleicht auch die Troubleshooter nicht immer erst auf die letzte Sekunde gebraucht werden, welcher wäre das? Oder vielleicht auch einfach ein Tipp, der Ihnen so am Herzen liegt.
00:25:07-6
-
Maik Pfingsten:
Also, was mir spontan einfällt, ist Vertrauen. Ich habe so oft erlebt, dass das einfach das war, was am Allermeisten gefehlt hat in den Unternehmen. Die Manager vertrauen den Mitarbeitern nicht, die Mitarbeiter vertrauen ihren Managern nicht und dadurch entsteht ein Riesenkonflikt in der Kommunikation.
Ich verstehe die Ursachen zum Teil. Ich kann nicht überall jetzt mit meinen Mitarbeitern reden als Manager und Mitarbeiter müssen verstehen, dass es manchmal Situationen gibt, wo ich auch nicht alle Informationen bekommen kann, aus taktischen Gründen, aus strategischen Gründen. Was aber nicht bedeutet, dass der Manager schlecht ist, sondern das hat einen guten Grund, dass manche Entscheidungen oder manche Kommunikationen.
So ein Freund von mir, Bernd Geropp hat das so schön auf den Punkt gebracht, in einer seiner Episoden, wo er eben sagte: „Ja es kann sein, dass das Top-Management die Vorgabe bekommen hat, von einem Gesellschafter eben, sie machen jetzt unter allen Standorten halt einen Leistungswettbewerb und von den 6 Standorten werden 2 geschlossen. Und zwar die Zwei, die am wenigsten performt haben. Das heißt, der Top-Manager geht jetzt hin und sagt dem Team: Wir müssen die nächsten vier Wochen Gas geben.“
Das Team denkt aber: Um Gottes willen, weiß der eigentlich nicht, dass wir alle hier landunter sind? Ist dem eigentlich völlig klar, was der von uns hier will? Er darf es aber nicht sagen, weil er unter Umständen an der Stelle halt zur Verschwiegenheit angehalten wurde, um die Ergebnisse nicht zu verfälschen. Aber er macht das natürlich im Sinne seiner Mitarbeiter, weil er will ja, dass sie gut sind, dass das Ergebnis dann auch dazu führt, dass sie da weitere sichere Arbeitsplätze haben.
Das heißt, Vertrauen ist ein ganz wesentlicher Punkt sowohl, dass das Management in seiner Form und Aufgabe als Führungskraft dieses Vertrauen schenkt an die Mitarbeiter. Gerade in unserem Kontext, wo wir in der Regel alles Geistesleister sind, oftmals auch mit akademischen Hintergründen, sind wir keine dummen Menschen, das bedeutet, ich muss das Vertrauen haben, auch Aufgaben abzugeben und Verantwortung auch abzugeben, aber gleichzeitig auch als Mitarbeiter das Vertrauen haben, dass die Leute schon da sind, weil sie diese Rolle auch gut ausfüllen als Manager und nicht immer drüber lästern wie schlecht mein Chef ist.
00:27:08-2
-
Petra Koch:
Ja. Weil vieles sieht man auch nicht, was dahinter steckt. Das ist eben, das erkennen die Leute dann erst, wenn sie eine Stufe höher gerutscht sind sozusagen.
00:27:16-1
-
Maik Pfingsten:
Richtig. Genau.
00:27:17-1
-
Petra Koch:
Klasse. Vielen, vielen Dank fürs Interview. Super interessant.
00:27:20-6
-
Maik Pfingsten:
Sehr gerne.
00:27:21-2
-
Petra Koch:
Vielen Dank.
00:27:21-9
-
Maik Pfingsten:
Gerne.
00:27:22-8
Ihr Feedback
Wir freuen uns über eine Bewertung des CIO Podcasts bei Apple Podcasts und den anderen Portalen!
Fünf Sterne stehen für „gefällt mir sehr gut“. Herzlichen Dank!
Wie gefällt Ihnen diese Folge des CIO Podcasts? Senden Sie Ihr Feedback, Anregungen und Wünsche einfach über das Kontaktformular direkt an die Redaktion des CIO Podcasts (nicht öffentlich):
[contact-form-7 id=“189″ title=“CIO Podcast“]
Weitere Podcast Folgen finden Sie hier.