Vor kurzem verstarb unser sehr geschätzter Herr Nachbar. Ich ahnte schon immer, dass er besondere technische Fertigkeiten besaß. Es war wirklich beeindruckend, wie er, mit Ü 90, vor zwei Jahren sein Balkonkraftwerk installierte.
Er stand im Unterhemd und wehendem Haar vor der Garage, um sich die Teile für den Flaschenzug zu flexen, mit dem er die Panels auf den Balkon zog. Das erinnerte ein wenig an Doc Brown aus zurück in der Zukunft.

Nun durften wir einen kleinen Blick in seine Wohnung werfen. Es wimmelte von sauber verlegten Kabeln, Dioden, Blinklichtern in jeder Ecke.

Man erklärte uns, dass einige Lampen blinken, wenn Post im Briefkasten ist, oder jemand die Treppe hinaufgeht.
Ich bin wirklich beeindruckt von den Fertigkeiten des alten Herrn.
Wer weiß, vielleicht hat er lange vor Alexa das Smarthome erfunden.

Aus aktuellem Anlass: Man löst das Auslastungsproblem in einer Organisation übrigens nicht dadurch, dass man mehr Druck ausübt. Derzeit habe ich in einem Ehrenamt die Situation, dass die Hauptamtlichen mehr Druck auf die Ehrenamtlichen ausüben, um die Arbeit noch bewältigen zu können.

Druck ist rein physikalisch mit Kraftaufwand verbunden. (Druck = Kraft / Fläche). Die „Fläche“ im Ehrenamt ist leider recht klein.
Druck versucht zu entweichen. Wer schon mal einen Schnellkochtopf zu früh geöffnet hat, weiß, was ich meine.

Aus dem Ehrenamt kann man natürlich einfach entweichen - und darin sehen gerade die Menschen, denen ihr Amt am Herzen liegt, gerade eine Gefahr.

Eine Ehrenamtliche: „Der derzeitige Druck erzeugt bei mir eher den Drang zur Revolte oder zum Hinwerfen, als mich noch mehr einzusetzen.“

Wir sollten unsere Kräfte lieber dafür einsetzen, gemeinsame Lösungen auszuarbeiten, unsere Kräfte für die Sache einzusetzen, als Druck auszuüben.

Was haben uns die 80er-Jahre eigentlich gebracht? Richtig: Modern Talking und den Begriff „Leuchtturmprojekt“. Letzteres habe ich aber erst vor ca. 10 Minuten gelernt, der Begriff verursacht bei mir aber ähnlich viele Herpes-Bläschen (Herpes monetäres), wie das Erstgenannte.

Wikipedia: „Mit dem Begriff Leuchtturmprojekt wird ein vorbildliches Vorhaben bezeichnet, das neben dem eigentlichen Zweck auch eine Signalwirkung für zahlreiche Folgevorhaben haben soll. Neben dem Erfolg ist daher auch eine große Bekanntheit beabsichtigt. In Unternehmen wird dies gerne bei Richtungsänderungen oder Neuausrichtungen verwendet . Die Verwendung des Begriffs ist seit etwa 1980 nachgewiesen“

Den Begriff Leuchtturmprojekt höre ich in zwei Fällen:

1. Die Sales-Leute haben (erfreulicherweise) ein neues Projekt an Land gezogen. Sie hoffen nun, dass ein erst zu 103% ausgelastetes Projektteam wie eine Motte ins Leuchtturmlicht fliegt und sofort starten will.
2. Ein superwichtiger Kunde, meist aus dem Bereich „Food“ oder „Automotive“, ist der Meinung, dass wir für dieses großartige Leuchtturmprojekt unsere Tagessätze mal eben um 50% senken, oder am besten kostenfrei arbeiten.
   

Ich habe da leichte Bedenken, denn wo viel Leuchtturmlicht ist, ist auch viel Schatten. Ist Euch eigentlich schon aufgefallen, dass Leuchttürme selten an einer gemütlichen Stelle stehen? Ein Leuchtturm steht dort, wo es ungemütlich ist: Klippen, Untiefen, Tod, Gefahr, Möwenscheiße.

Nach dieser Definition eines “Leuchtturmprojektes” ist man also als Dienstleister in der ständigen Gefahr, auf die eben erwähnten Klippen aufzulaufen oder auf Möwenscheiße auszurutschen. Das ist beides nicht schön, denn im Projekt kostet Ausrutschen bekanntlich Geld. Aber was soll’s dafür haben wir ja diesen großartig wichtigen Kunden. Natürlich sollte man großartige Projekte mit Signalwirkung als Chance sehen und diese positiv angehen – aber bitte nur, nachdem man die Risiken vernünftig bewertet hat. Wenn man zusätzlich noch den Tagessatz senkt, liegt das Projektrisiko noch mehr auf der Seite des Dienstleisters. Ich habe den Verdacht, dass der drohende Geldverlust auch diese seltene Form des Projekt-Herpes (Herpes monetäres) auslöst. Ich lasse das mal untersuchen.

Hier noch eine Schnappschuss vom Leuchtturm aus dem Beitragsbild 😉

*Eine selbstkritische Auseinandersetzung mit alten Projekthasen.*

Zur weiteren thematischen Auseinandersetzung wechseln wir an dieser Stelle wieder in unser DesastrÖÖs-Übungsfeld, den Projektbauernhof

Da stehe ich nun, als alter Projekthase und ehemalige Führungskraft, die unter den alten Umständen keine Führungskraft mehr sein wollte, und bin nun Teil eines agilen Teams – auf einem neuen Projektbauernhof, also bei einem neuen Arbeitgeber.

Der Hof befindet sich mitten in einem agilen Wandel. Raus aus der alten Welt, die durch Prozesse und Hierarchie an vielen Stellen gelähmt wurde, hin zu einer schnellen und kundenorientierten Organisation aus selbstorganisierten Teams. Das ist großartig, aber hat auch seine Schattenseiten, denn der eine oder andere Kollege nimmt diesen Wandel vielleicht anders war: Hinein in ein Chaos. *(Anm.: Vielleicht braucht es aber auch Chaos, damit neue Ordnung entstehen kann. Teenager 2 praktiziert diesen Wandel gelegentlich in seinem Zimmer.)*

Ich bin Profi im Hinblick auf Chaos. Ich habe viel Chaos produziert und viel Chaos behoben. Als alte Hase habe mir jedes meiner grauen Hasenhaare beim Entwickeln, beim Codereview, oder später als Projektleiter oder Lenkungskreis redlich verdient – meistens durch kleinere oder größere Desaster.
Und nun, angekommen auf dem neuen Bauernhof und ausgestattet mit einem reichhaltigen Erfahrungsschatz an desastrÖÖsen Projekten, versteht man die Kollegen, die sich verwirrt in manche Ecken des Hofs umsehen und sich „WTF?” denken.

Der Drang, die Welt zu retten

Der Bau des neuen Hühnerstalls erfolgte ohne Baugenehmigung, beim Projekt „Wir werden Bio“ war „Bio“ gar nicht definiert, das Produkt „Eier aus dem letzten Jahrzehnt“ war in der Produktion viel zu teuer und hatte keinen echten Businesscase, und die Anlage zur Kuhmassage hat eine Verfügbarkeit unter 98,3%, um nur einige Beispiele zu nennen.
Da muss doch endlich mal jemand durchgreifen, die Weilt retten, oder auch „agil durchregieren“ wie kürzlich jemand sagte. Muss man das?

Bei diesem partiell gefühltem Chaos auf dem Hof beginnt natürlich schnell das Gegacker des Federviehs:
„Hier denkt keiner mehr mit!“
„Wir brauchen EIER !!!11!1!!1!“
„Die brauchen mal einen Erwachsenen Projektleiter!“

Apropos Erwachsenen: Was ist eigentlich meine Rolle als Erwachsener in der Kindererziehung? (Ja, der Vergleich hinkt, aber ist ein junges, sich bildendes Team in einer völlig neuen Unternehmenskultur nicht manchmal vergleichbar mit einem Teenager, der nach Erfahrung und Orientierung sucht?)
Wenn die Kinder beginnen, mit dem Rad zur Schule zu fahren, fährt man vielleicht ein- bis fünfmal mit. Man schaut, ob sie schon sicher fahren, erklärt die Verkehrsregeln und mahnt zu Obacht an den gefährlichen Stellen.
Irgendwann lässt man die Kinder alleine fahren und achtet nur noch darauf, dass sie beim losfahren einen Helm tragen. Später kontrolliert man auch das nicht mehr, denn wer mündige Mitmenschen erziehen will, muss sich aus der Rolle des Kontrolleurs verabschieden und vertrauen – wohl wissend, dass es auch schief gehen kann.

Welche Rolle sollten also wir, die alten Hasen, in der neuen Arbeitswelt einnehmen? Als erstes sollten wir natürlich einfach nur teilnehmen. Wir sollten begleiten, unterstützen, befähigen – aber sicher nicht kontrollieren oder zu viel bremsen.

„Ewig im Gestern“ oder „vernünftig“?

Hier droht Gefahr: Wer im Wandel manchmal mahnend den Finger hebt, wird oft fälschlicherweise als „verliebt in die alte, hierarchische Arbeitswelt“ wahrgenommen. Es bleibt zu hoffen, dass die Firmen der neuen Arbeitswelt die alten Hasen nicht aufs Abstellgleis der „gestrigen Bremser“ stellen, sondern die Rolle des fachlichen „Befähigers“ erlauben und fördern. Viele Firmen setzen zwar Coaches ein, um die Transformation zu begleiten, das agile Denken zu fördern und die Organisation zu hinterfragen und zu verändern – aber was passiert mit dem fachlichen operativen Geschäft in jungen Teams?
Dort, wo Aufgaben umverteilt werden, wo neue Menschen sich in neue Themen einarbeiten, dort braucht man die alten Hasen mit ihrem [Wissen und Können](https://it-fettchen.de/2019/01/08/ueber-laternen-und-schwerter/).----

Liebe Organisationswandler: Schafft diese fachliche Unterstützungsrolle. Ihr zeigt den alten Hasen damit Eure Wertschätzung. Außerdem unterstützt ihr die jungen Teams und die Kunden werden es Euch danken.

Liebe Teams: Nicht jeder, der Unterstützung anbietet, will „agil durchregieren“.

Liebe „alte Hasen“: Hört auf, die Welt im Alleingang zu retten, Superhelden gehören in Marvel-Filme, aber passen nicht in eine wertschätzende Teamkultur. Setzt Eure Kräfte im Team ein, unterstützt, warnt vor gefährlichen Stellen, aber lasst los und lasst die jungen Kollegen erst mal losfahren.

Über Punkrock, Kaffee für Teetrinker und Motivatoren.

„Should I stay or should I go now?
Should I stay or should I go now?
If I go there will be trouble
An’ if I stay it will be double
So come on and let me know“
The Clash

Wann wird es Zeit, den Beruf, die Aufgabe oder gar den Arbeitgeber zu wechseln? Hier eine kleine Entscheidungshilfe in vier Ausbaustufen.

Methode 1: Fühle ich mich wohl?

Falls Ihr diese Frage mit „Nein“ beantwortet, will ich ehrlich sein: Methode 1 ist alleine nicht valide. Ja, natürlich sollte man sich im Job wohlfühlen, aber das ist nicht immer in der Verantwortung der Kollegen oder der Chefs. Falls ihr euch nicht wohlfühlen solltet, ist dies alleine kein Grund für einen Wechsel, sondern eher ein Grund zum Hinterfragen:

• Warum fühle ich mich nicht wohl?
• Wer oder was ist daran schuld, dass ich mich nicht wohlfühle?
• Was müssten andere ändern, damit ich mich wohlfühle?
• Was liegt vielleicht auch an mir selbst?
• Was sollte ICH ändern, damit es besser geht?
• Wer ist WIKLICH daran Schuld, dass ich mich nicht wohlfühle?
• Würde es mir woanders besser gehen, oder würden meine Probleme mit mir den Job wechseln…

Methode 1 lässt zu viele Fragen offen. Man sollte immer erst versuchen, Dinge zu verbessern, bevor man kapituliert. (Siehe „Für weniger #mimimi”)

Ganz wichtig zu Stufe 1: Man kündigt niemals in einem „temporären Tal”.
Methode 1 ist alleine also nicht hilfreich, aber vielleicht helfen ja die Methoden 2-4, um die richtige Entscheidung zu fällen.

Methode 2: Verdienst sein und verdient haben

Einer unserer Chiefs im Unternehmen formulierte es so:

„Ich stelle mir jedes Jahr zwei Fragen:
1. Bin ich noch ein Verdienst für die Firma?
2. Hat die Firma mich noch verdient?
Wenn ich zwei Jahre lang eine der Fragen mit „Nein“ beantworte, wird es Zeit zu gehen.

Zu Frage 1: Wann ist man ein Verdienst für die Firma?

Das würde ich recht einfach beantworten: Wenn ich Wertschöpfung für die Firma erbringe. Dies kann ich tun, in dem ich Schrauben oder Quellcode produziere, also „produktiv“ bin, oder in dem ich als Service andere Kollegen unterstütze produktiv zu sein. Z.B. als Personalabteilung, Hotline, Reinigungskraft oder als Kaffeebereiter.

Bleiben wir bewusst beim abstrakten Beispiel des Kaffeezubereiters:

• Situation 1: Du machst hauptberuflich Kaffee, die Leute lieben Deinen Kaffee und trinken Kaffee: Super, läuft.
• Situation 2: Du machst Kaffee, aber alle in der Firma trinken lieber Tee.

Jetzt wird es eng, Du bist vermutlich kein Verdienst für die Firma. Aber auch hier gibt es verschiedene Denkansätze: Warum trinkt man lieber Tee? Schmeckt mein Kaffee vielleicht ganz furchtbar? Dauert meine Zubereitungsmethode zu lange? Brauche ich besseres Equipment? Lerne endlich, wie man guten Kaffee kocht – Problem gelöst.
Schwieriger wird es, wenn einfach niemand mehr Kaffee mag, Du also am Markt vorbei arbeitest: Du kannst Deine Qualifikation nicht einsetzen: Starte eine Werbeoffensive für Kaffee, oder lernen guten Tee zu kochen.

In einem Jahr wirst Du Dir, mach den Regeln meines Chiefs, die „Verdienst-Frage“ nochmal stellen. Bis dahin solltest Du das Problem gelöst haben. (Um vorschnelle Frust-Entscheidungen zu vermeiden, finde ich den “Jedes-Jahr-Ansatz” wirklich gut.)

Zu Frage 2: Hat die Firma mich noch verdient?

Auch hier, würde ich, im übertragenen Sinne mit „Wertschöpfung“ antworten: Welche Wert schöpfe ich aus der Firma? Nur Geld? Kann ich mich entfalten, mich einbringen? Wird meine Person geschätzt? Wird meine Arbeit geschätzt? Wie zeigt mir die Firma das? Welche Dinge sind mir eigentlich wichtig? Was sind meine Motivatoren?

Bei diesen Fragen kann Methode 3 weiterhelfen.

Methode 3: Motivatoren

Vor kurzer Zeit lernte ich die „Moving Motivators“ aus Management 3.0 kennen. (Link: Erklärung, Bestellung als Karten, PDF-Download). Was soll ich sagen, die Dinger sind genial. Es handelt sich um 10 „Spielkarten“ mit betrieblichen „Parametern“, die mir wichtig für mein Wohlbefinden sind. Diese Karten kann man sich erstmal in seine persönliche Prioritätenreihenfolge bringen.

(z.B.: Kann ich meine Neugier ausleben? Ist mir „Freiheit“ wichtiger als „Ordnung?)
Es gibt dabei kein richtig oder falsch, und jeder verbindet mit Begrifflichkeit wie Honor (Ehre) etwas anderes – aber das macht nichts, denn es geht darum, dass man über diese Dinge nachdenkt und sich selbst zusammen mit den Karten „sortiert“.

Passen die Dinge, die mir wichtig sind, zu meiner jetzigen Stelle? Was würde sich ändern, wenn ich die Aufgabe, die Abteilung oder gar die Firma wechsle? Verschieben sich meine Motivationen dadurch nach Oben oder nach Unten?

Methode 4: Grafischer Soll-IstVergleich

Die Moving Motivators kenne ich noch nicht lange, und sie geben auch nicht alle Parameter wieder, die bei der Jobentscheidung wichtig sind. Daher kann man gut mit einem grafischen Soll-Ist-Vergleich arbeiten, denn eine einfache Tabelle mit Vor- und Nachteile erlaubt zu wenig Nuancen.

Zunächst legt man sich die Parameter fest, die einem wichtig sind. Zum Beispiel:

Rubrik “Gestaltungsumfeld”:

• Verantwortung (niedrig/hoch)
• Mitgestaltungsmöglichkeit (niedrig/hoch)
• Einfluss der Firmenpolitik (bremst/unterstützt)
• Möglichkeit zur persönlichen Entfaltung (niedrig/hoch)
• „operative“ oder „strategische“ Tätigkeitsausrichtung

Rubrik „weiche Faktoren”

• Soziales Umfeld (schlecht / super)
• Chefverhalten (schlecht / super)
• Arbeitsauslastung (zu wenig / zu viel)

Rubrik “Hard Facts”

• Wie wichtig ist mit Titel / Headcount
• Gehalt
• Freizeit
• Anzahl Dienstreisen / Abwesenheit

Mit der folgenden Vorgehensweise, kann man grafisch darstellen, wie weit Soll und Ist auseinander liegen.

Hier ist auch noch viel Platz für ein drittes Dreieck. Wie würde sich „Soll/Ist“ verändern, wenn ich eine andere Aufgabe in meiner Firma annehmen würde?
Was würde ich bei einem Jobwechsel zu Firma xy verschieben?

Der Sams-Effekt

In Firmen ist es wie beim Sams: Man muss “genau” wünschen. Egal, Ob Du Dich also für Methode 1, 2, 3 oder Methode 4 hast: Rede darüber! Methode 3 und 4 sind eine gute Gesprächsgrundlage für ein Gespräch mit Deinem Chef oder der Personalabteilung. Weiß Dein Chef oder Deine Personalabteilung, was Dir wichtig ist? Kennt man Deine Motivatoren? Ist jemandem Deine Unzufriedenheit bewusst? Nein? Dann ändere das! Redet miteinander!

Aber: Wenn Du unglücklich bist, das Gespräch suchst und niemand auf Deine Bedürfnisse reagiert, gibt es nichts, wirklich absolut nichts, was Dich noch in der Firma halten sollte – wenn Du eine bessere Alternative hast.

Für mitlesende Führungskräfte: Wisst Ihr, was Euren Mitarbeitern wichtig ist? Warum nicht? Ich setze ich hier gerne nochmal den Link zu „Wie man seine Mitarbeiter motiviert.“ Keine Angst, dieser Post ist „etwas“ kürzer.

Eigentlich ist diese Formulierung irreführend, denn viel spannender ist die Frage, WO ich mein erstes Projekt erbte.
Ich will nicht zu viel verraten, aber in diesem Zusammenhang fiel mir erstmals auf, dass Herrentoiletten keine Notausgänge haben. (Eine Fehlplanung. Das wäre aus vielerlei Gründen notwendig.)

Eines Abends, mein Tagesgeschäft war erledigt, trocknete ich mir die Hände ab. Plötzlich kam der Herr Prokurist herein und freute sich, mich zu sehen. (Wo ist der verdammte Notausgang????). „Ach Stephan, schön Dich zu sehen, komm doch gleich mal in mein Büro, wir brauchen ja einen Neu-Projektleiter für den Kunden XYZ.“

Nun muss man wissen, dass der „Alt-Projekt-Leiter“ für den Kunden XYZ am Vorabend, unweit von der gerade durch den Prokuristen verstellten Toilettentür, weinend vor seinem Rechner saß. „Ich halte diesen Scheiß nicht mehr aus, ich werde jetzt Berufsschullehrer.“ Einen Abend später, ohne Fluchtmöglichkeit, wurde mir klar, dass er sein Ding durchgezogen hatte. Ich habe ihn nie wieder gesehen. Lieber Ex-Kollege: Falls Du das hier liest: Hoffentlich bist Du inzwischen an einem besseren Ort, ich verstehe Deine Tränen, denn dieses Projekt war ein Horrortrip. (Wobei ich sehr bezweifle, dass es in der Berufsschule einfacher ist als beim Kunden).

Jahre später, bei einem anderen Arbeitgeber, durfte ich Kollegen aus allen Fachbereichen in Sachen „Projektmanagement“ schulen. Dieses Kloprojekt war dabei das Paradebeispiel für Fehlbesetzungen, fehlgeschlagene Planung, mangelhaftes Risiko- und Stakeholdermanagement.

• Der Dienstleister-PL, also ich, wurde unausgebildet in die Rolle des PLs geworfen (vorher war ich Senior-Entwickler)
• Der Kundenprojektleiter kam zu dem Posten, weil er Neffe vom Chef war – total überfordert
• Der Betriebsrat war gegen die Einführung der Software. Das Erste, was mir die Kunden GF bei meinem Besuch zeigte, war ein Aushang des BR, warum der BR die Software nicht will
• Den Mitarbeitern wurde nie erklärt, warum man die Software einführt
• usw.

In Folge kam es zu Sabotage-Akten. Es wurde mit Stahlkugeln auf Hardware geschossen, Verkabelung durchgeschnitten usw.

Das Projekt ging also genau so besch***** weiter, wie es auf der Herrentoilette begann.
Aber es wahr sehr lehrreich.

Ein Freund berichtete mir kürzlich von seinem letzten Familienurlaub: Die junge Familie ging zusammen die letzten 100 km des Jakobswegs, mit dabei war ein Vorschulkind.

„Auf diesem Weg habe ich viel für meine tägliche Projektarbeit gelernt: Mit einem kleinen Kind erschien uns der Weg manchmal endlos, das Wetter war mies, aber wir hatten ein klares Ziel vor Augen und wollten dieses Ziel unbedingt erreichen. Und am Ende haben wir etwas Lustiges festgestellt: Obwohl wir, wegen der Kleinen, viel langsamer gingen als andere Pilger, kamen wir vor denen an, die uns überholten. Vermutlich waren die Schnelleren auch schneller erschöpft und brauchten mehr Pausen.“

Vor ein paar Tagen war ich in einem SlowFood-Restaurant, das war großartig. Langsamer ist manchmal besser, im Falle des Pilgerwegs war langsamer sogar schneller. Nach diesem Urlaubsbericht würde ich ja gerne mal ein SlowProject machen.

Wenn man einigen Managementbüchern Glauben schenkt, erfordern komplexe Situationen immer ein selbst denkendes Hochleistungsteam, denn jegliche Form der Hierarchie behindere den Mitarbeiter in seiner Entfaltung und ist somit kontraproduktiv. Hierarchien funktionieren somit nur in der „Routine“ niemals aber in komplexen, einmaligen Problemstellungen. Ist das so? Sind Hierarchien im Projekt schädlich?

Einer meiner ehemaligen Geschäftsführer wird gerne mit dem Satz „Projekt ist Krieg !!111!!!11!“ zitiert.

Der Vergleich ist mir zwar zuwider, aber lassen wir uns kurz auf die Denkweise meines Ex-Geschäftsführers ein. (Ihr liegt richtig, wenn ihr vermutet, dass er nicht gerade ein Freund der Schwarmintelligenz und von autonomen Teams war.)

WTF?

Ihr werdet jetzt vielleicht denken: „Liebes IT-Fettchen, das ist doch Taylorismus in Reinstform, sozusagen Punish, don’t support“.

Jein. Ich bin überzeugt, dass ein gutes Team fast immer die bessere Lösung findet, als ein ein einzelner Chef in der Hierarchie. Dazu müssen aber Voraussetzungen erfüllt sein:

• Es muss ein tatsächlich ein gutes Team sein (und sich nicht nur selbst als solches empfinden)
• Es muss Entscheidungsoptionen geben – in manchen Projekten gibt es diese nicht.

Kann man auf Hierarchien verzichten?

Meine Ansicht: Nein. Man kann Hierarchien flach gestalten, aber selbst wenn ich ein tolles Projekt habe, also ohne Krieg, sind gelegentlich Entscheidungen notwendig, für die man eine Hierarchie braucht. Z.B. die Abwägung zweier konkurrierende Projekte beim Kampf um Mitarbeiterkapazität und Zeitpläne.

Dies könnte man vielleicht auch durch ein Projektmanagement-Office außerhalb der Hierarchie steuern, ich halte das aber für schwierig.

Ich kenne nur wenige Firmen, die mit ernst zu nehmenden Methoden arbeiten, um projektübergreifend zu steuern.

In den vergangenen Jahren habe ich Teams und Konzepte kennengelernt, bei denen die Mitarbeiter nicht nur eigenverantwortlich Probleme lösten, sondern auch etwa demokratisch über Neuanstellungen und Gehälter entscheiden. Ich glaube, dass solche Konzepte funktionieren, aber spätestens, wenn es unangenehme Personalentscheidungen gibt, ist „man“ doch wieder froh, dass eine Hierarchie die Drecksarbeit macht.

Apropos Drecksarbeit

Vor ein paar Jahren hatte ich den geilsten und cleversten Programmierer in meinem Team, der jemals auf Erden gewandelt ist – zumindest hielt er sich selbst dafür. Die Realität sah anders aus: Ich habe fast jeden Abend bis 23:00 daheim gesessen, Codereview gemacht, ihm am nächsten Tag seine Fehler erklärt, neue Aufgaben gegeben. Support bis an die Schmerzgrenze.

Trotz Erklärung, warum sein Programm auf keinen Fall funktionieren könne, und sogar zum Stillstand beim Kunden führe, wollte er es beim Kunden aktivieren – nur um zu beweisen, dass es doch funktioniert. Zum Glück bemerkte ein QS-Kollege im Codereview die fatalen Fehler und stoppte die Aktivierung.

Hier griff dann doch die „Punish-Variante“. Wenn ich kein Höchstleister bin, muss ich eben den Befehlen des „Generals“ gehorchen.

punisch vs. punish

Im letzten Blogpost spielte mir die Rechtschreibkorrektur einen Streich: Aus „Support don’t punish“ wurde „Support, don’t punisch“. Damit ihr nicht googeln müsst: Punische Kriege, Hannibal, Elefanten, Alpen usw.

Vor ein paar Jahren schenkte mir meine großartige Ex-Chefin ein Buch: „Das Hannibal-Prinzip – Mutig führen, menschlich bleiben“. Hannibals Führungskonzept basierte demnach auf den folgenden Werten: Mut, Disziplin, Intelligenz, Vertrauen und Menschlichkeit. Wenn dies eine Reihenfolge ist: Ich würde Vertrauen und Menschlichkeit weiter nach vorne bringen, denn diese Werte sind für mich wichtiger, als die Intelligenz des „Generals“.

Ich glaube das nicht, dass Projekt Krieg ist, aber es schadet auch nichts, wenn man die Werkzeuge des Krieges beherrscht. Ich glaube aber auch nicht, dass Hierarchien schaden – wenn diese mit Mut, Disziplin, Vertrauen, Menschlichkeit und Intelligenz führen.

Als ich kürzlich in Wien war, ging ich abends an der Donau entlang, und fand dort dieses wunderbare Graffiti. Ein Graffiti, ein Satz – das kleine Einmaleins der Führung.

Auf den nächsten Metern, bis zur nächsten Eisdiele, gingen mir viele Gedanken durch den Kopf:

• Kann man eine Abteilung / ein Projekt ohne „disziplinarische Maßnahmen“ führen?
• Brauchen „agile Teams“ eigentlich einen Teamleiter? (Eine Frage, die immer wieder in PMCamp-Sessions auftauchte)
• Sind Hierarchien im Unternehmen grundsätzlich ein veraltetes und böses Relikt aus der Zeit des Taylorismus?
• Liegt die Zukunft eines Unternehmens eher in agilen, selbst verwaltenden Teams?
• Was heißt eigentlich „Support“?
• Wie findet man die richtige Dosis für den Support?
• Was ist die Grenze zwischen „Strafe“ und „notwendiger Korrektur“?
• Strafen eigentlich nur die Chefs, oder ist ein stinksaurer Kollege oder Azubi im Teammeeting / beim Essen nicht auch eine Form der Strafe?

Fragen über Fragen, mit denen man eine ganze Blogserie oder ein Management-Buch füllen könnte. Ein Buch möchte ich Euch und mir nicht zumuten, eine Blogserie wäre vielleicht eine Idee. Zumal ich mir vorgenommen habe, dass jeder Post von mir nur maximal 5-10 Minuten Eurer Lesezeit verbrauchen sollte. Mit diesen Graffiti und den Fragen lasse ich Euch jetzt erst mal ein paar Tage alleine.

Ich weiß nicht, wie viele Stunden ich in den letzten zwei Jahren auf den Knien zugebracht habe, um Löwenzahn zu zupfen. Wie ihr auf dem obigen Bild erkennen könnt, ist mir das super gelungen.

Bezüglich meiner heimischen Löwenzahnkulturen habe ich zwei Theorien entwickelt: Entweder der Löwenzahn ist viel tiefer verwurzelt, als ich zupfe, oder es kommt ständig neuer Löwenzahn dazu.

Der Löwenzahn in meinem Garten verhält sich demnach exakt so, wie schlechte Prozesse auf dem Projektbauernhof. Tief verwurzelt, scheinbar nicht zu besiegen, und täglich kommen neue Pflänzchen dazu. Vielleicht auch beides.

Im heimischen Garten habe ich inzwischen „Verbündete“: Kind 2 durfte heute erst an die xbox, nachdem es zehn gezupfte Löwenzahn vorweisen konnte. (Scheinbar machte ihm das Spaß, denn es wurde ein ganzer Eimer.)

Ich zupfe einfach weiter. Falls das alles nichts hilft, zupfe ich im nächsten Jahr einfach mit einem Bagger.

Nachtrag, 24. April 2018: Heute fand ich zufällig dieses wunderbare Bild der @miniphilosphen in meiner twitter-timeline. Im Zusammenhang mit den Prozessen auf dem Projektbauernhof wirft dieses Bild berechtigte Fragen auf….

Mein kleiner Beitrag zu blinden Aktionismus.

Es war einmal ein Projekt – das scheiterte. Glaubt man der Statistik, ist dies nicht ungewöhnlich. Es war aber ungewöhnlich, dass der Lenkungsausschuss viel zu spät mitbekommen hat, wie schlecht es um das Projekt stand. Nach dem Abbruch begann also eine Fehleranalyse und man entdeckte einen spannenden Faktor, der wohl zum Scheitern des Projektes beitrug: Die Plüsch-Falle.

Schon zu Beginn des Projektes war klar, dass hier ein Kommunikationsstarker Projektleiter hermuss. „Vor allem die menschliche Komponente ist uns besonders wichtig“, „wir kommunizieren hier immer vollkommen offen und ehrlich“ – und so begann es auch. Man lobte die tolle Projektatmosphäre und ruckzuck waren Dienstleister und Kunde beim Du. Nach anstrengenden Meetings zog man gelegentlich um die Häuser und telefonierte sogar privat, um den favorisierten Sportclub des anderen PLs zu dissen.
In dieser kuscheligen Plüschatmosphäre hätte alles wunderbar funktionieren können, wenn sich im weiteren Projektverlauf der Projektkumpane nicht als PLVP (Projektleiter-Vollpfosten) entpuppt hätte.

Und damit begann vermutlich ein Kommunikationsproblem: Mails, die mit „Lieber Torben-Pascal“ beginnen, gehen selten mit „Deine Arbeitsweise ist ein Projektrisiko, weil Du alle Meilensteine verbummelst“ weiter.

Kleinere und größere Probleme wurden daher eher mündlich auf dem kleinen Dienstweg kommuniziert, das reicht ja auch, denn jeder vertraute darauf, dass der andere schon seine Vorgesetzten (Lenkungsausschuss) informieren wird. Schließlich möchte man ja niemanden anschwärzen.

Irgendwann, als die Verzögerung immer größer und die Kosten immer höher wurden, wechselte die Stimmung von „plüschig“ zu „frostig“ : Der Ton in den Mails verschärfte sich und wies auf Verzug bei den Meilensteinen und eine Explosion der Kosten hin. An diesem Punkt wurde die Kommunikation dann auch komplett offen und ehrlich: „Ich kann nicht damit umgehen, wenn man mich unter Druck setzt und mir Fristen setzt.“
Schade eigentlich. Beruf verfehlt. Und das Projekt auch.

Liebe Mit-Projektleiter: Nennt mich altbacken oder konservativ, ich habe nichts gegen das „Du“, auch eine gute Projektatmosphäre ist hilfreich und wichtig. Aber haltet Eure Projektpartner auf professioneller Distanz. Als Hüter der PMAxt empfehle hier gerne: Haltet eine Axtlänge Abstand.

– Gedanken zum PMCamp Rhein-Main 2017 „Projektarbeit zwischen Marathon und Sprint." –

Der Unterschied zwischen „Laufen“ und „Laufen“.

Was Laufen angeht, bin ich Profi. Wenn ich mich richtig erinnere, beherrsche ich das Laufen schon über 20 Jahre. Es soll sogar schon Kinderfotos geben, auf denen ich einen Fuß vor den anderen setze, um von A nach B zu kommen.
(Mein älterer Bruder würde sagen, dass „B“ dabei vermutlich SEINE Gummibärchen oder Kekse waren, aber das ist so nicht richtig.)

Was Laufen angeht, bin ich Profi. Dachte ich, als ich vor ein paar Monaten beschloss, als Ausgleich zum Bürostress mehr Sport zu machen. Das Programm: Rückentraining, Rad – und Laufen.

Und so dauerte mein erster Lauf – seit der tragischen „Siegerurkunde“ beim Sportfest 1987 – genau 1 Minute und 37 Sekunden, denn nach 1 Minute und 36 Sekunden bekam ich einen Wadenkrampf.

Ich war zu schnell, war zu schlecht gedehnt, meine Bänder durch das Sitzen im Büro viel zu kurz usw.

Nach diesem desastrÖÖsen Ergebnis las ich ein Buch über Laufen, unterhielt mich mit laufenden Freunden, laufe mit Pulsuhr, habe bessere Schuhe und erziele seither deutliche Fortschritte. Ich habe nun Wissen, Technik und Ausrüstung. Läuft.

Wir lernen: Es gibt einen Unterschied zwischen „Laufen“ und „Laufen“.

Projektkrämpfe

Vor einiger Zeit kam eine Pojektleiterin zu mir: „Der Kunde X hört nicht auf uns. Die haben noch nie ein Softwareeinführungs-Projekt gemacht und halten es immer noch für den Idealweg am BigBang-Tag sieben(!!!!) Systeme gleichzeitig einzuführen. Völlig beratungsresistent.“

Merkt ihr was? Das ist wie, wenn meine längste Laufstrecke sich auf Sofa-Kühlschrank-Sofa bemisst und ich mich zum Ironman Hawaii anmelde. Nachdem ich die 1,8 km geschwommen bin, stelle ich dann plötzlich fest: „Scheiße, du brauchst ja ein Fahrrad.“

Je nach Studie scheitern zwischen 10 und 30% der IT-Projekte, 60% gelten als „schwierig“. Warum? Ganz einfach: Es fehlt, wie bei meinem ersten Lauf, an Wissen (bzw. Erfahrung), Technik und Ausrüstung.

Das Traurige daran ist, dass bei jedem gescheiterten Projekt nicht nur Zeit und Geld verbrannt wird, sondern dass vor jedem nicht erreichten Meilenstein ein fußlahmer Projektmitarbeiter kriecht.

Von der Couchpotato zu Ironman

Liebe Kunden, falls ihr jahrelang auf dem Sofa gesessen habt:

• sucht Euch gute Berater, die Euch „Laufen“ beibringen, denn ihr könnt nicht „Laufen“.
• wählt kompetente Dienstleister, die prüfen, ob Ihr überhaupt ein Fahrrad habt.
• hört auf die Berater und Dienstleister – wenigstens manchmal.
• trainiert eure Projektmitarbeiter.

Mit einem guten Trainingsplan und etwas mehr Zeit klappt es auch mit dem Ironman.

Nachdem ich im Mai 2016 schon auf ironische Art und Weise erklärt habe, wie man sein Team lobt, möchte ich mich heute noch einmal ernsthaft mit dem Thema Lob auseinandersetzen. (Nachträgliche Anmerkung: Die Ironie haben damals nicht alle Leser verstanden und so musste ich das Axt-Logo mit „Ironie-Warnung“ in den Blog aufnehmen.)

In diesem Beitrag gibt es keine Ironie-Warnung, denn das Thema ist mir sehr wichtig. Es geht diesmal auch nicht um das Lob durch einen Vorgesetzten, denn warum sollte eigentlich immer nur der Chef etwas Nettes sagen? Stattdessen geht es mir heute um die innerbetriebliche Zusammenarbeit – sofern man auf dem einen oder anderen Projektbauernhof noch von Zusammenarbeit sprechen kann.

Egal wo man ist, ob intern oder extern, man hört immer mehr Gejammer: Die eigene Situation ist ganz furchtbar schlimm und alle anderen sind Schuld an allem Übel.

Hier einige Beispiele aus der Welt der Software:

• Der Vertrieb verkauft nur Mist und unrealistische Aufwände
• Die Produktentwicklung macht zu viele Fehler und kümmert sich nicht
• Die Projektteams kennen das Produkt nicht gut genug
• Das Projekt-Office nimmt zu viele Projekte an
• Und am schlimmsten ist das Controlling
• Ach nein, ich vergaß: Am schlimmste ist ja die Hotline

Ich bin sicher, dass jeder Leser diese #mimimi-Liste noch um mindestens 10 branchenunabhängige Punkte erweitern kann.

Gestern war ich im Rahmen meines Ehrenamtes auf einem kirchlichen Workshop zum Thema „Gemeindeaufbau“. Hier wurde eine spannende Frage gestellt: Wenn wir wollen, dass Menschen sich wohl fühlen, warum nörgeln wir so viel aneinander herum und loben so wenig?

Ich finde, diese Frage lässt sich prima auf Unternehmen übertragen: Wenn wir wollen, dass Mitarbeiter sich wohl fühlen, sollten wir ALLE weniger und konstruktiver nörgeln. Könnten wir zu Beginn eines Gesprächs einfach mal davon ausgehen, dass unser Gegenüber gerne arbeitet und sein Bestes gibt? Im nächste Schritt, könnten wir das unserem Gegenüber sogar sagen – klingt verrückt, entspannt aber die Grabenkämpfe im Unternehmen.

„Von einem guten Kompliment zehre ich zwei Monate.“
(Mark Twain)

Im gestrigen Seminar wurde eine „Lobquote“ angesprochen. Für alles Negative, dass ich loswerden will, muss ich mindestens zwei positive Sachen benennen.
Ich empfinde diesen Gedanken als sehr spannend. Nehme ich Kritik nicht viel ernsthafter, wenn ich das Gefühl habe, mein Gegenüber meint es eigentlich gut mit mir?

Im Grunde wollen doch alle nur das Eine: Gut zusammenarbeiten und ein gutes Produkt ausliefern. Das ist nicht nur eine Sache der Chefs.

„Willst Du Dein Land verändern, verändere Deine Stadt. Willst Du Deine Stadt verändern, verändere Deine Straße. Willst Du Deine Straße verändern, verändere Dein Haus. Willst Du Dein Haus verändern, verändere Dich selbst.“

Arabisches Sprichwort

Ihr kennt das: Ihr sitzt in einem Meeting, und irgendjemand erklärt euch einen vollkommen dämlichen Prozess. „Irgendjemand“ könnte ein Kunde oder ein Kollege sein. Um es im Text zu vereinfachen, nennen wir „irgendjemand“ nun Fred. (So heißt meine Ratte im Ava). Manchmal weiß Fred sogar, dass der Prozess vollkommen dämlich ist und begründet das Dasein des Prozesses mit den Worten „Das ist historisch gewachsen“.

Beim Thema „historisch gewachsen“denke ich sofort an IT-Regel 18. Aber immerhin hat Fred erkannt, dass sein Prozess „Optimierungspotential“ hat, weil er ein verdammtes, unkontrollierbares Chaos ist.

Masters of the Universe

Schwierig wird es, wenn Fred glaubt, dass SEIN Dasein und das Dasein des Prozesses miteinander verknüpft sind*.
Dann erfahren wir sehr schnell, dass

• man es schon immer so gemacht hat (auch bekannt als „Argument des Todes“)
• und dieser Prozess niemals nie nicht geändert werden darf, da sonst das Universum aus den Fugen gerät.

Für Freds Universum trifft das vielleicht sogar zu. In einem solchen Meeting kommen wir sehr schnell in eine typische Kopf-Tisch-Situation. (Anmerkung: Nehmen Sie bei Kopf-Tisch-Situationen niemals ihren eigenen Kopf.)

Gelegentlich erzähle ich allen Freds beim Mittagessen die folgende alte Geschichte. Manche sagen, sie käme aus Indien, andere vermuten ihren Ursprung im Internet:

In einem Kloster lebte ein alter Meister, der jeden Tag seine Andacht hielt. Da er nun mehrfach in seiner Andacht von einer Katze gestört wurde, befahl er, die Katze während seiner Andacht anzubinden. Einige Jahre später starb der alte Meister und ein neuer Meister nahm seinen Platz ein. Die Katze wurde weiter während der Andacht angebunden. Wieder einige Jahre später starb die Katze. Um eine Katze während der Andacht anbinden zu können, wurde eine neue Katze gekauft. Im Lauf der folgenden Jahre kamen Besucher aus anderen Klöstern und sahen, dass in diesem Kloster immer eine Katze zur Andacht angebunden wurde. Sie beschlossen, dies für ihr eigenes Kloster zu übernehmen. Einige Jahrzehnte später füllten die Gelehrten dicke Bücher über die liturgische Bedeutung des Anbindens einer Katze während der Andacht.

Projektkatzen

In unseren Projekten finden wir zig angebundene Katzen. Wir finden Prozessbeschreibungen über das Anbinden von Katzen, Sicherheits- und QS-Standards, technische Spezifikationen des Halsbands und vieles mehr. Ja, das Anbinden einer Katze ist ein hochkomplexer Vorgang, der nur durch speziell geschulte und jahrelang erfahrene Katzenanbindungsbeauftragte gelöst werden kann.

Liebe Katzenanbindungsbeauftragte: Hört auf zu versuchen, diese hochkomplexen Prozesse zu steuern. Hochkomplexe Prozesse sollte man nicht steuern, sondern sie vereinfachen oder abschaffen.

Lasst die Katzen endlich los.

*) Siehe auch „Wie man sein Leben durch Automation erschwert“

Unter dem Hashtag #MethodeEgal ruft das Projektmagazin zur Blogparade zum Thema Projektmanagement-Ansätze und -Systeme auf. Offen gesagt: Ich empfinde diese Diskussionen als genauso müßig, wie die Suche nach dem einzig wahren „Führungsstil“. Denn die allgemeingültige Antwort ist: Es gibt keine allgemeingültige Antwort. Unterschiedliche Projekte haben unterschiedliche Bedingungen und erfordern unterschiedliche Methoden, unterschiedliche Mitarbeiter erfordern einen unterschiedlichen Führungsstil.

Thomas Michl beschreibt in seinem Blogpost, dass es nicht auf die Methoden, sondern viel eher auf die Geisteshaltung eines Projektleiters ankommt. Werte wie Offenheit, Respekt und die Art der Kommunikation zeichnen einen Projektleiter aus. Ich stimme hier vorbehaltlos zu.

Neben den von Thomas aufgelisteten sozialen Skills, sind mir aber zwei „Geisteshaltungen“ besonders wichtig:

1.) Das ständige Hinterfragen der eigenen Rolle, der Methodik und des Führungsstils.
2.) Die Flexibilität, nach dem Hinterfragen, die gewählte Methoden anzupassen.

Projekt-Exkurs

Auf einem meiner Projektbauernhöfe gab es einmal zwei parallele Projekte:

Projekt 1:
Typ: Interne Produktentwicklung eines neuen Produkts
Aufwand: > 100 Tage, Ziel: Bestmögliches Produkt
Personal: heterogenes Team, Senioren und Junioren gemischt
Methode: Agil (Scrum)
Rezept zum Erfolg: Arbeiten auf Augenhöhe, sammeln und umsetzen vieler guter Ideen

Fazit: Product Owner zufrieden, Team stolz auf Leistung und Produkt

Projekt 2:
Typ: Kundenprojekt, Steuerung einer vorhandenen Anlage
Aufwand: > 100 Tage Entwicklung, Abbildung klar definierter Prozesse, zeitlich sehr knapp
Personal: Ein Senior Entwickler, ein Senior Berater, ein Junior, viele Azubis
Methode: Klassisch. Klar definierte Arbeitspakete, Senior definiert, Junior setzt um
Rezept zum Erfolg: Fokus auf Ausbildung, starke Kontrolle

Fazit: Projekt erfolgreich, Kunde zufrieden, enormer Ausbildungsschritt für die Azubis, Team stolz auf das Ergebnis.

Zeitgleich wurden zwei Projekte umgesetzt, die nicht unterschiedlicher sein könnten.Das Erfolgsrezept liegt für mich in der Beurteilung des Projekts, der Einschätzung des Teams und der daraufhin abgestimmten Methode.

Kriterium 1 zur Methodenauswahl: Das Projekt

Ein agiles Projekt profitiert von vielen Köpfen beim Entwurf, von Kreativität, Storytelling, „dynamischen“ Prioritäten und so weiter. Wenn ein Entwicklungsteam etwas komplett neues entwickelt und dabei viel konzipiert, bieten sich agile Methoden mehr an, als bei „starren“ Zielen.

Wenn eine Software jedoch etwa eine Produktionsanlage steuern soll, ist die Kreativität eher zweitrangig. Es gibt genau definierte Prozesse, genau definierte technische Schnittstellen, genau definierte Kosten. Es gibt auch keinen 80%-Start mit den wichtigsten Anforderungen aus Anwendersicht. Am Tag X muss die Maschine zu 100% laufen. Für mich sind solche Projekte eher einen Fall für klassisches Projektmanagement.

(Und wehe es sagt jemand „Waterfall“, denn “Waterfall” ist ein Modell und keine PM-Methode. Außerdem erfordert jedes Projekt eine hohe Anpassungsfähigkeit und Flexibilität. Meiner Meinung nach gibt es keine reinen “Waterfall-Projekte”, also keine “nicht-agilen” Projekte. Zumindest habe ich in 18 Jahren IT-Geschäft kein Projekt ohne ständige Veränderung und Anpassung erlebt.)

Ich persönlich halte Scrum & Co z.B. bei „internen“ Projekten für die bessere Methode. In Kundengesprächen stelle ich immer wieder fest, dass der Kunde GENAU wissen will, welche Funktion er am Tag X zum Preis Y bekommt. (Das liegt bei mir vielleicht an der Branche).

Kriterium 2 zur Methodenauswahl: Das Team

Wenn wir ehrlich sind, bekommen wir nicht immer das Team, das wir gerne hätten.

Der Idealfall wäre natürlich das dynamische, hochmotivierte Team von Könnern im Mix mit ein paar lernwilligen Anfängern. Wenn wir ein solches Hochleistungsteam haben, wird dieses Team jedes Projekt umsetzen können – und vermutlich wird sich das Team wohler fühlen und die besseren Ergebnisse erzielen, wenn das Projektteam beispielsweise mit Scrum arbeitet.

Wir haben aber zu wenig „ideale“ Teams. Wir haben Teams voller Anfänger, denen (noch) die Basiskenntnisse fehlen, um eigene Ideen zu entwickeln. Wir haben Teamkollegen, die unzuverlässig sind und deren Fertigstellungstermine ständig kontrolliert werden müssen. Wir werden während des Projektes versuchen, Mitarbeitern Verantwortung zu übertragen, die keine Verantwortung tragen wollen – oder können. Der Kunde wird uns vielleicht Menschen in das Projekt setzen, die noch ihre wahre Qualifikation suchen (Zitat eines Chefs: „Pfeifen haben immer Zeit”). Im schlimmsten Fall werden wir interne oder externe Projektmitarbeiter haben, die das Projekt hassen und es sabotieren werden. Ein solches Team ist anders zu führen, als unser Wunschteam. (Stichwort #PMAxt).

Methode egal? Hauptsache schwimmen?

Ein guter Projektleiter (er)kennt sein Team – und passt die Methode an. Da wir über Hochleistungsteams sprachen, bietet sich der Vergleich zum Leistungssport an. Da eine Bekannte von mir Schwimmerin ist, gehen wir für einen Vergleich ins Wasser:

• Mit einer Bande von neunjährigen Seepferdchenschülern werde ich kein olympisches Gold holen.
• Jemanden, der nicht teamfähig ist, setze ich nicht in einer Staffel ein.
• Es gibt nur wenige Sportler, die in allen Disziplinen (z.B. Brust- oder Rückenschwimmen) sehr gut sind.
• Einen Rückenschwimmer schicke ich nicht in ein Brust-Rennen – und umgekehrt.

Ein guter Trainer wird den Seepferdchen erst das Schwimmen beibringen, bevor er auf Turniere fährt. Wie bleibe ich über dem Wasser? Erst danach beginnt das Leistungstraining.
Ein guter Trainer wird eine Staffel zusammenstellen, die funktioniert und die „schwierigen Fälle“ motivieren oder als Einzelsportler einsetzen.
Ein guter Trainer wird die Disziplin für seine Sportler aussuchen, in der sie zu Höchstleistungen fähig sind und sie dann fördern und fordern. Zum Fördern und Fordern wird er manchmal der kumpelhafte Motivator und ein andermal der erbarmungslose, fiese Drill Sergeant sein. So viel zum Thema Sport, denn von Sport verstehe ich noch weniger als von Projekten. 😉

Fazit: Die Methode ist nicht egal

Meiner Ansicht nach, ist die Methode nicht egal. Die Methode muss zum Projekt, aber vor allem zu jedem einzelnen Mitarbeiter des Teams passen. Projekte erfordern Höchstleistung des gesamten internen und externen Teams. Der Projektleiter muss die richtige Methode wählen, um Stärken seines Teams zu fördern und die Schwächen auszugleichen.

„Nun sag, wie hast du’s mit der Produktivität? Du bist ein herzlich guter Entwickler, allein ich glaub, du hältst nicht viel davon” (Ungefähr so steht es in Goethes “Faust”)
Ja, mit der Produktivität ist es so eine Sache. Für die einen ist es Religion, für die anderen ist es eine weltfremde Idee des Controllings.

Rumgeeiert

Auch auf unserem Projektbauernhof lebte mal ein Controller. Dem war das Thema Produktivität sehr wichtig.
„Ein Huhn ist produktiv, wenn es täglich ein verkaufsfähiges Ei legt.“
Seit dieser Zeit gibt es in unserem Projektmanagementsystem ein Feld, in dem man die Sollproduktivität eines jeglichen Hofbewohners pflegen kann.

Aber: Kann man Produktivität in der Softwareentwicklung wirklich messen?
In einer konventionellen Eierproduktion klappt das recht gut. Ein Ei pro Tag und Huhn sollten schon drin sein. Da erscheinen die 1,56 Eier pro Jahr, die in St. Petersburg zwischen 1885 und 1917 produziert wurden, geradezu skandalös unproduktiv. Eines dieser 50 Fabergé-Eier erbrachte 2007 bei einer Auktion bei Christie’s auch nur schlappe 12,5 Mio Euro.

Nun würden sich vermutlich viele Entwickler gerne als verkannte Künstler sehen, die vom bösen Controlling zu Unrecht bewertet werden (Wie wäre es in Lines of Code?)

Ich denke, die Wahrheit liegt dazwischen. Wir codieren nicht, um Faberge-Code zu produzieren oder coole Funktionen zu basteln. Wir programmieren, um Geld zu verdienen. (Zumindest sitzen die meisten von uns in dieser Klemme.)
Um Geld zu verdienen, brauchen wir entweder
a) ein verkaufsfähiges Produkt oder
b) abrechenbare Personentage.
Am besten haben wir beides.

Unproduktive Könner

Trotzdem mag ich das Wort „Produktivität“ in diesem Zusammenhang nicht, denn die alleinige Betrachtung von KPIs machen die besten Mitarbeiter zu den unproduktivsten Kostenfaktoren.

– Die Experten, die um Hilfe gebeten werden, wo kein anderer mehr weiterweiß.
– Die Hotliner, die den Mist der anderen ausbaden und den Kunden beruhigen.
– Der Projektleiter-Guru, der anderen die verkorksten Projekte rettet.

Sprich: Die Könner, ohne die auf dem Bauernhof nichts mehr klappen würde, sind so betrachtet unproduktiv – und sind meistens sehr frustriert, wenn sie SO betrachtet werden.

Das Ergbenis zählt

Im Projektgeschäft ist die Bewertung der Produktivität von Einzelpersonen sinnlos. Man kann nur das Ergebnis des gesamten Teams bewerten. Nur so wird man dem Könner gerecht, der allen anderen ermöglicht „produktiv“ zu sein. Doch am Ende zählen nur zwei Fragen:
1. Ist der Kunde zufrieden (Qualität, Zeitplan…)?
2. Wie viel Personentage hat das Team in das Projekt gesteckt – um wie viel Geld zu verdienen?

Meine Sollproduktivität im System ist übrigens Null.
Das schaffe ich meistens.

Loben: Jemanden, sein Tun, Verhalten o. Ä. mit anerkennenden Worten (als Ermunterung, Bestätigung o. Ä.) positiv beurteilen u. damit seiner Zufriedenheit, Freude o. Ä. Ausdruck geben. (Quelle: Duden)

Aber: Richtiges Loben will gelernt sein. Dazu gibt es ein paar einfache Grundregeln:
– reflektieren Sie die vergangenen Leistungen
– Zeigen Sie Vertrauen in Ihr Team
– Zeigen Sie Wertschätzung für Ihr Team
Um es Ihnen etwas zu vereinfachen, habe ich hier ein paar Lobes-Prachtexemplare für Sie zusammengestellt:

1. “Das lief ja viel besser als sonst”

Zweifellos ein sehr gelungenes Lob, denn hier wird die erste Grundregel des Lobens wunderbar umgesetzt:
Beim Loben sollte immer auch die vergangene Leistung des Gelobten reflektiert werden.
Schließlich soll ein Lob zu weiteren Leistungssteigerungen motivieren.

2. “Ich hätte nicht gedacht, dass ihr das schafft“

Hier kommt der zweite wichtige Aspekt des Lobes in den Fokus: Vertrauen in das Team.
Natürlich muss Vertrauen erst erarbeitet werden. Und das ist Ihrem Team ja in diesem Projekt mal gelungen. Ausnahmsweise.

3. „Das hätte ich alleine nicht viel besser machen können”

Dies ist mein persönliches Lieblingslob. Gehen Sie also sparsam damit um, damit niemand übermütig wird.
Es zeigt die perfekte Umsetzung von Regel 3: Wertschätzung.
Was wären Sie ohne Ihr Team: Eben. Nicht viel besser.

Die traurige Wahrheit

Kommen wir zur traurigen Wahrheit: Ich habe alle drei “Lobe” schon im Umgang von Teamleitern mit Teams gehört.
Also: Erst denken, dann loben.

Zum Abschluss bliebe noch ein Zitat von Karl Simrock:
Des Pöbels lob hält nicht die Prob.

Ich arbeitete mal mit einem Projektbauernhof auf dem einfach JEDES Projekt ein Erfolg war.
Auf den ersten Blick erschien mir diese Erfolgsquote unrealistischer als ein osteuropäisches Wahlergebnis in den Achtzigern, doch schon bald erkannte ich, dass die folgenden drei Punkte immer zum Projekterfolg führen:

Das agile Ziel

Jedes junge Projekthühnchen weiß, dass eine gute Zieldefinition der Schlüssel zum Erfolg ist.
Dabei ist besonders wichtig, dass Sie ihr Ziel immer erst NACH dem Projekt definieren.
Das ist wie beim Sport:
Kein vernünftiger Mensch käme VOR dem Laufen auf die absurde Idee zu sagen „Heute laufe ich die 10 km unter einer Stunde“.
Der erfahrene Läufer kennt die Risiken des Umknickens und der plötzlich auftauchenden Bierbrunnen am Wegesrand. Der erfahrene Läufer trabt los, und schaut, wie weit er kommt.
Puuhhhh – Seit Sonnenaufgang 3,4 km geschafft. Und davon nur ein kleines Stück mit dem Taxi.
CHAKAAAA Ziel erreicht.

Die Ehda-Regel

Die Ehda-Regel ist sehr einfach, aber richtig angewendet führt sie garantiert jedes Projekt zum Erfolg:
Erfassen Sie niemals die internen Aufwände eines Projektes, denn die Mitarbeiter sind ja „eh da“.
Bevor die Kollegen also nutzlos herumgammeln, können sie sich auch 250 Stunden in das Projekt einbringen, dass am Ende einen Gewinn von 3,70 € erwirtschaftet.
CHAKAAAA Ziel erreicht.

Die Liga der außergewöhnlichen Projektmitarbeiter

Ein Geheimtipp:
Der Projektleiter, am besten sogar das ganze Projektteam, sollte nur aus Führungskräften bestehen.
Niemand wird es jemals wagen, den Projekterfolg infrage zu stellen.
CHAKAAAA Ziel erreicht.

Es war einmal vor langer Zeit in einem weit, weit entfernten Büro eines IT-Leiters:

“Was machen Sie denn da?”
(Der IT-Leiter war umgeben von mehreren Stapeln Papier auf Stühlen, Tischen und Fußboden, während der teuflische Drucker schnaufend weitere Wälder durch den Papierschacht zog.)
“Ich hatte wieder einen Fehler in meiner Access-Abfrage. Jetzt muss ich alle Reports manuell sortieren.”
“Wieviele sind das?”
“Meistens über 1000.”
“Meistens? Wie oft machen Sie das?”
“Jeden Mittwoch.”
“Warum machen Sie das mit Access? Und warum erzeugen Sie nicht erst ein PDF, prüfen die Abfrage – und drucken dann?”
“Merken Sie sich das: Wenn wir hier zu viel optimieren, wird man diese IT hier nicht mehr brauchen.”

Hier wurde ich zum ersten mal auf ein Phänomen aufmerksam, dass ich hin und wieder auch in unseren Projekten entdecke:

Es gibt Unternehmen, die WOLLEN sich nicht verbessern, WOLLEN keine Prozesse optimieren.
Sie ahnen es vielleicht: Projekte in solchen Firmen erfordern entweder viel Zeit und Stakeholderanalysen – oder die #PMAxt. Manchmal auch beides.

Inzwischen habe ich eine Art Frühwarnsystem für optimierungsresistente Kunden entwickelt:

• Viele alleinige Wissensträger: +8 Punkte
• Server aus der Jahrhundertwende, deren Funktion keiner kennt, aber auch keiner abschalten will: +13 Punkte
• “Wir müssen nichts dokumentieren, wir kennen unsere Prozesse”: + 10 Punkte
• Patchfelder vor denen selbst Stephen King Angst hätte: + 5 Punkte
• “Wir brauchen keine Lastenhefte. Unterschreiben Sie einfach auf diesem PostIt”: +25 Punkte
• Zusätzlich gibt es noch branchenspezifische Extrapunkte.

Fazit

Mal im Ernst:
Die IT sollte ein Innovationsgeber im Unternehmen sein, Firmen fit machen für die Zukunft.
Leider werden IT-Abteilungen aber oft nur als “Kostenfaktor Kellerkinder” wahrgenommen – und auch so behandelt.
Wie viel Innovation kann ein Management von einer IT erwarten, die bei jeder Optimierung Angst um ihr Existenz hat?