Wie man im Produktionsumfeld Projekte vergeigt

"Also bitte, was soll denn so schwer daran sein, eine Produktionsplattform am Leben zu halten? Schwerkraft gibt's gratis, Strom, Hardware, Gebäude und Netzanschluss stellt der Rechenzentrumsbetreiber, Du musst doch allenfalls dafür sorgen, vor Langeweile nicht einzuschlafen."

In einer idealen Welt wäre dies tatsächlich wahr. Ein gut aufgesetztes System müsste so stabil sein, dass man es sich selbst überlässt und allenfalls in einer Hochlastsituation eingreift. Die Realität ist freilich anders. Ständig bastelt jemand an der Produktion herum, sei es, weil sie wider Erwarten doch nicht stabil läuft, oder weil die nächste Aktualisierung ansteht.

Die Katastrophe in Japan zeigt in großem Maßstab, was passiert, wenn das Unvorhergesehene eintritt. Wir sehen, warum im Vorfeld gepfuscht wird, dass man sich vor allem gegen die Fälle absichert, von denen man möchte, dass sie eintreten und die vernachlässigt, von denen man fürchtet, dass sie eintreten. Wir erleben, wie schlechte Informationspolitik aussieht und wie bemitleidenswert hilflos Improvisation sein kann. Sollte dieser Planet noch mit einem blauen Auge davon kommen, haben die Überlebenden ein Musterbeispiel für Missmanagement gesehen, das sich in kleinerem Maßstab täglich überall abspielt. Man wird Bücher darüber schreiben, was schief ging, warum es schief ging, einige werden diese Bücher sogar lesen, noch viel weniger werden sie verstehen, und dann wird man sie vergessen. Ich nehme mir die Freiheit, einige der Aussagen vorweg zu nehmen und sie auf das kleine Fitzelchen Welt zu übertragen, aus dem ich komme: Dem Betrieb produktiver Serverplattformen für Großunternehmen. Nach einem guten Vierteljahrhundert mehr oder weniger professioneller Arbeit in der IT maße ich mir an, einen Großteil der möglichen Fehler selbst begangen oder zumindest erlebt zu haben.

Der folgende Text ist weder sachlich, noch ist er freundlich. Schauen Sie in die Adresszeile Ihres Browsers, wenn Sie sich fragen, warum. Sollte Sie die eine oder andere Passage beleidigen, lesen Sie den Abschnitt ruhig noch einmal und überlegen Sie dabei, was daran eigentlich so beleidigend ist. Was Sie dann erleben, nennt man Wahrheit.

Wenn Sie einen Kunden verlieren wollen, erfüllen Sie seine Wünsche.

Als Dienstleister befindet man sich in einer unlösbaren Situation. Der Kunde weiß in der Regel nicht, was er will und kommt mit irgendwelchen Anforderungen, die er sich von seinen Beratern hat einflüstern lassen. Im Moment möchte er beispielsweise ganz bestimmt "in die Cloud", was auch immer das sein mag. Ich kenne IT-Dienstleister, die einfach ihre drei VMWare-Instanzen "Cloud" genannt haben, wohl wissend, dass dieses Gebilde etwa so sehr eine Cloud ist wie Guido Westerwelle ein echter Außenminister - nur, um im Angebot das Zauberwort auftauchen zu lassen. Sie haben nun die Wahl: Entweder setzen sie den ausdrücklichen Kundenwunsch um - was auf keinen Fall funktionieren wird - und bekommen dann vorgeworfen, warum sie die offensichtlich unsinnigen Anforderungen nicht korrigiert haben, oder Sie setzen es so um, wie es richtig ist und müssen sich bei jedem kleinsten Fehlverhalten unter die Nase reiben lassen, Sie hätten gegen die Vorgaben verstoßen. Kurz: Sie können nur verlieren. Der Vorteil der zweiten Möglichkeit liegt allerdings darin, dass man mit etwas Glück und Können ein System hingestellt bekommt, das im Gegensatz zum garantiert unsinnigen Kundenwunsch wenigstens so gut läuft, dass der Kunde kaum Gelegenheit zum Lästern hat.

Schlechte Nachrichten sind gute Nachrichten.

Vor ihren Projektmitarbeitern lassen die Leiter kaum eine Gelegenheit aus, das Alphatier zu geben, den Macher zu mimen, der Mann zu sein, der hoch geheime Informationen von der Geschäftsführung erhält, von denen er nur so viel verraten darf, dass nur Supertypen wie er in den Genuss dieses Wissens kommen dürfen. Gegenüber den Kunden verwandelt sich Mister dicke Hose schlagartig in ein handzahmes Schoßhündchen, das seinen Daseinsgrund vor allem darin versteht, gute Nachrichten zu verbreiten, um bloß nicht den allmächtigen Kunden zu vergrätzen. Es kommt zwar nicht oft vor, aber ab und zu sitzt auf Kundenseite ein Profi, und der weiß nur zu genau, was er von dem ihm präsentierten Disneyidyll zu halten hat. Er will keine gute Laune haben, er will informiert sein, und wenn der Projektleiter penetrant nur das erzählt, was er sich traut, weiß der Kunde, dass gelogen wird. Natürlich freut sich niemand über schlechte Nachrichten, aber darum geht es auch nicht. Der Kunde muss planen können, und jede Nachricht, die ihm hilft, Risiken abzuschätzen und eventuell Puffer einzuschätzen, ist wertvoll.

Zeitdruck ist ein schlechter Handbuchautor.

Das Stichwort "Dokumentation" wird Ihnen in diesem Artikel mehrfach begegnen. Ich bin insofern ein untypischer Vertreter meiner Spezies, als ich eine gute Dokumentation sehr zu schätzen weiß. Das großspurige Technikergewäsch, guter Code dokumentiere sich selbst, und überhaupt gäbe es Vorgänge, die so komplex seien, dass man sie unmöglich aufschreiben kann, halte ich für das selbstgefällige Gelalle inkompetenter Laien, die allein deswegen schon gefeuert gehören, weil sie offenkundig außerstande sind, sich allgemein verständlich zu artikulieren. "Genie ist ein Prozent Inspiration und neunundneunzig Prozent Transpiration." schrieb Edison, und das gilt gerade in der IT, deren Akteure sich gern als entrückte Genies sehen. Unaufgeschriebenes Wissen ist praktisch überhaupt kein Wissen. Was nützt mir ein mit Kenntnissen vollgestopfter Mitarbeiter, wenn ich jedes Mal, wenn der Kerl bei Rot über die Ampel läuft, Schweißausbrüche bekomme, weil das Geschäftsmodell meiner Firma gerade knapp der Stoßstange eines LKWs entrinnt?


"Aber wenn ich mein ganzes Wissen aufschreibe, werde ich ersetzbar." Wenn Sie so wenig leisten, dass Ihre Position von der Existenz einer Textdatei abhängt, kann dies sein. Wer wirklich etwas kann, behält seinen Posten - nicht obwohl, sondern weil er ihn beschrieben hat.


Das Schreiben guter Dokumentation kann so sein wie das Schreiben guten Codes - zutiefst befriedigend. Auf ein gutes Handbuch kann und darf man genau so stolz sein wie auf ein gutes Programm, und genau wie ein wirklich gutes Programm hackt man ein gutes Handbuch nicht mal schnell in einer halben Stunde als lästige Fleißarbeit in den Rechner, sondern nimmt sich Zeit, entwickelt eine Idee, ein Konzept, das man beim Schreiben vor Augen behält. Was ganz bestimmt nicht funktioniert, ist das Schreiben von Kiloware, unlesbarem Unsinn also, den man zusammenschmiert, weil der Projektleiter mit autistischer Penetranz auf das besteht, was er mit Dokumentation verwechselt: Arial Blocksatz, Firmenlogo rechts oben mit Projektbeschreibung und Abgrenzung sowie vollständiger Auflistung der Seriennummern aller jemals im Gerät verbauten Festplatten. 


Wer garantieren möchte, dass im Handbuch keine einzige verwertbare Information steht, verhindert, dass es dann geschrieben wird, wenn der Autor gerade herausgefunden hat, wie eine Sache funktioniert und am ehesten geneigt ist, dieses Wissen hinzuschreiben. Statt dessen prügelt man sein Team dazu, die Plattform irgendwie hinzuhuddeln. "Aufschreiben könnt ihr ja später, wenn alles fertig ist" - und sich niemand mehr so richtig erinnern kann, was man anstellen musste, bis es lief.

Schreien ersetzt kein Talent.

Viele Projektleiter verwechseln Mutwillen mit Führungsstärke. Es gibt Situationen, in denen man einfach eine Entscheidung braucht und es gar nicht so wichtig ist, ob es die optimale ist. Das heißt aber nicht, dass grundsätzlich jede Entscheidung ohne langes Überlegen aus dem Bauch heraus getroffen werden soll, und vor allem sollte man nicht glauben, dass Emotionalität Inkompetenz kompensiert.

Ein guter Vorgesetzter ist die Firewall des Teams. Nach innen sorgt er dafür, dass der Laden funktioniert, nach außen vertritt er die Gruppe und - das ist ein entscheidender Punkt -  steckt die Schläge für sie ein. Führung heißt Verantwortung übernehmen - in allen Situationen. Ich kann  mich nicht für die Erfolge meiner Leute feiern lassen, wenn ich nicht gleichzeitig bereit bin, für deren Fehler geradezustehen.

Der Grat zwischen Führungsstärke und Kasernenton, zwischen Freundlichkeit und Quengelei ist schmal. Sowohl der Drill Instructor als auch der Quengler begehen den gleichen Fehler, indem sie Argumente durch emotionalen Druck ersetzen. Wenn etwas technisch, finanziell, personell oder zeitlich nicht möglich ist, habe ich als Leitungskraft zwei Optionen: Entweder ich sorge durch Umverlagerung oder Bereitstellung neuer Mittel dafür, dass es doch möglich wird, oder ich lasse es bleiben. Durch Herumgebrülle oder nerviges Betteln schaffe ich vielleicht auch das eine oder andere Mal, meine Leute breitzuschlagen und das Unmögliche doch zu ermöglichen, aber derartige Aktionen gehen ausnahmslos auf Kosten meiner Mitarbeiter. Ich verspiele meinen persönlichen Kredit, und ich lauge mein Team aus. Gute Chefs wissen das und sorgen im Gegenzug ihrerseits dafür, dass für ihre Leute kleine Schurkereien möglich sind, welche die Firmenbürokratie eigentlich verbietet. Schlechte Chefs verwechseln Ausnahmen mit Strategie und ziehen ihre Erpressernummer konsequent weiter durch, bis sie auch den letzten Mitarbeiter verbrannt haben.

Was ist schlimmer als ein Manager? Zwei Manager.

Der Glaube, dass Manager etwas unglaublich Tolles und Wertvolles sind, hat in der Wirtschaft religionsartige Züge angenommen. Ich bestreite nicht, dass Management wichtig ist und ein Projekt voran bringt. Die Konsequenz, dass zwei Manager entsprechend wichtiger sind und ein Projekt noch voranner bringen, ist so grenzenlos dumm wie die Vorstellung, ein Hammer ließe sich doppelt so gut handhaben, wenn man ihn mit zwei Griffen versieht.

Was in der realen Welt unmittelbar einleuchtet, führt in der IT zu maßlosem Erstaunen. Ich habe in Projekten mit immensem Zeitdruck gearbeitet. Um wenigstens halbwegs im vorgegebenen Ramen zu bleiben, forderte ich meinen Manager auf, mir entweder sofort mehr Mitarbeiter zuzuweisen oder bestimmte Aufgaben zu streichen. Am nächsten Tag kam er freudestrahlend zu mir: "Ich habe hier die Lösung für dich." - "Oh fein. Da du keinen neuen Mitarbeiter anschleppst, gehe ich davon aus, dass du mir mitteilst, welche Aufgaben wir vorerst bleiben lassen." - "Noch viel besser. Ich habe noch einen neuen Manager gefunden, der dich unterstützen wird." Zu diesem Zeitpunkt hatte ich bereits sechs Vorgesetzte, die ständig in meinem Büro herumlungerten und von mir "den aktuellen Status wissen" wollten. Der Vorteil des Managers Nummer sieben bestand wenigstens darin, so unglaublich faul zu sein, dass ich ihn nach drei Jahren überhaupt erstmals zu Gesicht bekam. Insgesamt aber frage ich mich, wie heruntergekommen ein System sein muss, in dem alle überzeugt sind, ein Schiff führe dann besonders gut, wenn sich auf der Brücke die Kapitäne drängeln und alle sich zu fein sind, im Maschinenraum die Kohlen zu schippen. Es reicht nicht, die Arbeit zu verwalten, man muss sie auch erledigen.

Nur eins ist schlimmer als keine Dokumentation: Schlechte Dokumentation.

Der Vorteil nicht vorhandener Dokumentation ist wenigstens, dass hier ganz offensichtlich etwas fehlt. Viel häufiger aber sind Fälle, in denen tatsächlich irgendetwas geschrieben wurde, was aber gänzlich nutzlos ist. Ich wurde einmal zu einem Einsatz gerufen, bei dem es darum ging, die Ursache für das schlechte Laufzeitverhalten eines Servers zu finden. Ich musste auch nur wenige Stunden betteln, bis sich der Projektleiter dazu herabließ, mir die Dokumente zu schicken. Auf den ersten Blick sah alles ganz großartig aus: Architekturdokumente, Modulbeschreibungen der Software und Kommunikationsdiagramme. Auf den zweiten Blick hin stellte sich die Lage alledings viel schlechter dar: Seitenweise Bestellanforderungen, Marketinggefasel und vor allem Datumsstempel aus einer Zeit, in der sich die gesamte Plattform noch im alten Rechenzentrum befand. Was komplett fehlte, war eine aktuelle Serverliste, eine Aufzählung der Admin-URLs, eine Beschreibung der Installations- und Logverzeichnisse und vor allem eine den jetzigen Stand wiederspiegelnde Darstellung, welcher Server mit wem auf welche Weise redet. "Ja Freunde, wie sieht denn eure Plattform im Moment aus?" - "Steht das nicht in der Doku?" - "Da steht drin, wie die Sache vor vier Jahren aussah, als ihr den Kram in Hannover aufgebaut habt. Inzwischen seid ihr mindestens einmal umgezogen, von Solaris auf Linux gewechselt, habt zwei Major Releases eures Applikationsservers eingespielt, und wenn ich richtig informiert bin, stammt die aktuelle Softwareversion auch nicht von IBM, sondern von euch. Ich habe also den Eindruck, dass eure Dokumentation nicht mehr ganz taufrisch ist." - "Ja, aber bekommen hast du sie." Damit Sie den geistigen Totalaussetzer des letzten Satzes richtig erfassen: Entscheidend war nicht die Qualität des Handbuchs, sondern allein die Tatsache, dass man seiner Pflicht nachgekommen war und es geliefert hatte. Wer sein Geschäft auf so epische Weise nicht verstanden hat, ist selbst mit Hartz IV noch massiv überbezahlt.

Erkennen Sie Todesmärsche.

Im englischsprachigen Raum pflegt man zu historisch belasteten Begriffen bekanntermaßen ein entspannteres Verhältnis als in Deutschland, weswegen man beispielsweise in der Softwareentwicklung von einem "death march" spricht, ohne darin eine Verhöhnung der Opfer des Nationalsozialismus zu sehen. Für Techniker ist auf Anhieb klar, worum es geht. Für Manager und andere intellektuell Herausgeforderte hier die Erklärung: Todesmärsche sind Projekte, die von vornherein zum Scheitern verurteilt sind, bei denen es keine Chance gibt, Anerkennung zu erringen, bei denen man sich nur blamieren kann und bei denen man am Ende nicht mehr bekommt als eine schlechte Bewertung und einen Tinnitus.

Was sind untrügliche Zeichen eines Todesmarschs?

• Das Projekt läuft schon geraume Zeit, wurde diverse Male verlängert und ist gerade im Begriff, einen weiteren Termin zu überziehen.
• Das Wissen konzentriert sich auf einige wenige Schlüsselfiguren, im Extremfall eine. Es gibt keine oder nur veraltete oder ausgesprochen schlampige Dokumentation.
• Die Plattform wurde von einer großen Beratungsfirma aufgesetzt, die mindestens einen Regalmeter Dokumentation hinterließ. Warum ist das schlimm? Weil Beraterfirmen kein Interesse haben, saubere Arbeit zu liefern, sondern ihre Mitarbeiter im Projekt einnisten wollen. Die Dokumentation sieht beeindruckend aus, aber es geht darin in etwa so sehr um das Projekt wie in DSDS um Musik.
• Die Fluktuation im Projekt ist hoch. Der Projektleiter hat vor Ihnen schon eine Reihe anderer Leute gefragt und kommt nun auf Sie. Anders gesagt: Alle guten Mitarbeiter sind verbrannt, jetzt braucht der Kerl Kanonenfutter.
• Technisch hört sich alles recht einfach an. Es wurden überwiegend Standardkomponenten eingesetzt. Diese sind allerdings veraltet und mehrfach unqualifiziert überarbeitet worden, so dass niemand mehr genau sagen kann, was auf der Platfform eigentlich vor sich geht. Kennen Sie das Gefühl, das einen beschleicht, wenn die selbe Applikation dreimal installiert ist, nur eine Installation funktioniert, man die anderen beiden Verzeichnisse aber nicht löschen kann, weil sie auch noch irgendwie verwendet werden? Das ist der Hauch des Todes.
• Es gibt keine Abnahmeumgebung.
• Es gibt eine Abnahmeumgebung, aber es wird gleichzeitig auf ihr entwickelt.
• Der Kunde hat Adminzugriff auf die Produktion.

Wie lautet die einzig sinnvolle Strategie, wenn man für einen Todesmarsch angeworben wird? Ablehnen. Sagen Sie dem Projektleiter ganz klar, in welche Sache er sie reinreiten möchte. Natürlich wird er sie dafür hassen, aber das wird er auch, wenn Sie den Todesmarsch - entschuldigen Sie die drastische Ausdrucksweise - nicht überleben - was der Fall sein wird, lassen Sie sich nichts Anderes einreden. Sie kürzen die Sache nur ab und erhalten sich Ihre Gesundheit.

Enge Kommunikation ist ein Segen. Enge Kommunikation ist ein Fluch.

E-Mail, Chat, Telefon - ein dreifach Hoch dem, der diese Technik schuf. Selbst Großraumbüros haben ihre Vorteile, wenn sie von Könnern konzipiert und von Mitarbeitern genutzt werden, die wissen, wie man mit dieser Büroform umgeht. Viele Konflikte und Missverständnisse lassen sich dadurch vermeiden, dass die Leute einfach intensiv miteinander reden. Ich habe erlebt, wie Arbeitsgruppen allein dadurch in Feindschaft gerieten, dass einige Mitarbeiter in ein anderes Gebäude verlegt wurden, das nur ein paar Minuten entfernt lag. Generell behaupte ich: Je enger die Teams beisammen hocken, desto besser funktionieren sie.

Wenn sich jetzt bei Ihnen Widerspruch regte, haben Sie Recht. Erstens sind nicht alle Leute gleich gestrickt. Es gibt brilliante Arbeiter, denen man eine Aufgabe in die Hand drückt, die dann für einige Zeit im Nichts verschwinden und dann mit einem perfekten Ergebnis wieder auftauchen. Solche Menschen sind todunglücklich, wenn man sie in die Legebatterienwelt des Großraumbüros pfercht. Ein anderes Phänomen tritt ebenfalls zu Tage, wenn man zu eng auf einem Haufen hockt: Man bekommt viele Kleinigkeiten erledigt, aber eine langwierige, große Aufgabe geht im Tagesgeschäft unter. Darüber hinaus bedeutet der kurze Gang zum Nachbartisch, dass man nichts mehr aufschreibt, und am Ende hat man sein kleines Klüngelründchen mit bändeweisem ungeschriebenem Wissen, in das man keine neuen Mitarbeiter einarbeiten kann, weil niemand in der Lage ist, strukturiert und komprimiert die Arbeit im Projekt zu beschreiben.

Die Antwort auf "kannst du mal kurz" lautet "nein", die auf "könntest du mal eben" lautet "stirb".

Es klang bereits im letzten Kapitel an: Kurze Kommunikationswege begünstigen das Tagesgeschäft und blockieren langfristige Projekte. Es gibt eine weitere Situation, in der man nichts weniger braucht, als ständige Unterbrechungen: Ausfälle. Unter Profis ist die Aufgabenverteilung klar: Einer übernimmt die Öffentlichkeitsarbeit und hält die Kunden im Zaum, der Rest der Gruppe kümmert sich um nichts Anderes als darum, die Plattform wieder ans Laufen zu bekommen. Die Kunst des PR-Menschen besteht vor allem darin, den Leuten im Maschinenraum jeden zusätzlichen Ärger vom Hals zu halten, gleichzeitig aber auf dem Laufenden zu bleiben, wie die Sache voran kommt und damit Nachrichtenbröckchen zu haben, die er der Kundenmeute verfüttern kann. Stellen Sie sich einen Notarzt vor, der gerade einen Prominenten zu retten versucht. Optimalerweise verbringt dieser Mann jede Sekunde komplett konzentriert auf die Rettung dieses Menschen. Was er ganz bestimmt nicht braucht, ist ein Oberarzt, der ihn pro Stunde für 5 Minuten in eine Pressekonferenz winkt ("Die Leute wollen wissen, was los ist, dauert auch nicht lang.") und Momente höchster Konzentration dadurch stört, dass er "mal kurz" den Visitenplan für den nächsten Tag durchgehen möchte oder "eben schnell" jemanden braucht, der sich den ausgekugelten Arm in Zimmer 4 ansieht. Binsenweisheiten? Banalitäten? Warum hält sich dann kein Projektleiter daran?

Selbst im Kapitalismus gibt es einen Unterschied zwischen "Mitarbeitern" und "Leibeigenen".

Warum ich zur Arbeit gehe? Weil mein Vermieter ein freundliches Lächeln als Bezahlung nicht annimmt. Mein Arbeitgeber ist zwar nicht optimal, aber laue Wischiwaschi-Typen wie ich kommen auch nur in lauen Wischiwaschi-Firmen unter. Was in der deutschen Unternehmenskultur über Jahrzehnte gut funktionierte, war die sachliche Unaufgeregtheit der eigenen Firma gegenüber. Natürlich versuchten gute Firmen, ihre Angestellen mit allerlei Annehmlichkeiten für die Firma zu begeistern, aber man gab sich keinen Illusionen hin, dass kaum jemand einen VW zusammenschraubt, weil er damit glaubt, die Welt zu verbessern, sondern weil die Bezahlung stimmt.

In der IT ticken die Uhren etwas anders. Hier linst man gern in Richtung USA und sieht, wie dort die Wal-Mart-Mitarbeiter jeden Morgen auf Linie gebracht werden. Hirnwäsche statt gut bezahlter, interessanter Arbeit - das muss doch auch bei uns gehen, und so pflastert man die Wände der Büroetagen mit Postern, die - am liebsten auf Englisch, weil man ja so unglaubich hip ist - parolenartig die vermurkste Firmenrealität schönlügen. Mein derzeitiger Favorit ist "Ich suche nicht, ich finde", mit dem die Propagandaabteilung des Intranet über die Tatsache hinwegzugehen versucht, dass auch mit der neu eingebundenen Suchmaschine selbst die Suche nach dem Namen des Firmenchefs nur unbrauchbaren Mist liefern.

Die Forderung nach Identifikation bleibt freilich nicht auf der allgemeinen Arbeitsebene stehen, sondern fordert zum klaren Rechtsbruch auf. Wer nur 10 Stunden pro Tag für die Firma arbeitet, von denen selbstverständlich nur 8 bezahlt werden, bekommt vom Projektleiter zu hören, er bringe sich nicht ausreichend ein. Der Einwand, nach deutschem Recht dürfe man aber nur maximal 10 Stunden am Stück arbeiten und liefere im Fall eines Verstoßes Grund für eine bis zur Kündigung reichende Abmahnung, wird mit der Bemerkung weggewischt, dann müsse man eben die Zeiterfassung fälschen  - was übrigens Grund für eine fristlose Kündigung sein kann. Der Arbeiter lässt sich also nicht nur auf eine Erpressung ein, er steht im Fall, dass es auffliegt, sogar noch als der allein Schuldige da.

Das ist übrigens genau der Turbokapitalismus, den wir an den Vereinigten Staaten und Japan so schlimm finden, und genau wie dort sind die Folgen offensichtlich: Massiv unzufriedene Angestellte wechseln die Firma, sobald sich die Gelegenheit bietet. Die Zurückgebliebenen fahren immer mehr auf Reserve, die Arbeitsergebnisse werden immer schlechter, und am Ende hilft keine noch so militant agierende Propagandaabteilung, die Schar der innerlich Gekündigten noch zu mehr als dem absolut nötigsten zu überreden.

Der Narr sucht Schuldige. Der Weise sucht Ursachen.

Das Projekt nähert sich dem Stadium, in dem selbst Manager, die sich das Koks mehltütenweise durch die Nase ziehen, nicht ganz umhin können, zu bemerken, dass sich der eine oder andere winzige Holperer eingeschlichen hat. Was jetzt folgt, ist dieses klägliche Schauspiel, in dem jeder die Schuld von sich weist und eilig auf den Nächsten zeigt. Am Ende bleibt es bei dem kleben, der nicht schnell oder überzeugend genug reagiert hat. Das Bauernopfer ist gefunden, wobei sich niemand dafür interessiert, ob es für das kollektive Eindreschen aus Projektsicht plausible Gründe gibt.

IT hat mit Moral so gut wie nichts gemein, selbst wenn man den Server von Greenpeace betreibt. Die Schuldsuche ist aber eine moralische Frage, und sie wird fragebedingt emotional ausgetragen. Was man in Wirklichkeit braucht, ist die Suche nach dem, was schief ging, was vom erwarteten Ergebnis - einer Verhaltensänderung der Beteiligten - her gleich ist, aber eine höhere Chance bietet, dass jeder über den eigenen Beitrag und darüber nachdenkt, wie es besser laufen könnte. Wer Schuldige sucht, greift Menschen in ihrer Persönlichkeit an. Wer Ursaschen sucht, gibt den Betroffenen die Chance, das Gesicht zu wahren.

Was haben wir gelernt? Dass wir nichts lernen wollen.

Immer, wenn ein Projekt mit besonders viel Schmackes gegen die Wand gesetzt wurde, gibt es im Anschluss eine "Lessons-Learned"-Sitzung. Die Idee klingt gut: Alle Beteiligten setzen sich zusammen, man bespricht, was schief lief, warum es schief lief, und beim nächsten Mal läuft alles besser. Da gibt es dann eine tolle Powerpoint-Präsentation, in der noch einmal alle Phasen des Projekts eingehend betrachtet werden, und eine Excel-Tabelle, in die man ganz viele tolle Ideen einträgt. Mein Beitrag lautet in der Regel: "Schmeißt das unfähige Entwicklerpack raus, stellt den Projektleiter an die Wand und jagt diese verlogene Bande vom Marketing zum Teufel." Das will natürlich keiner hören, also bringe ich in der Regel eine Kurzfassung des oben Geschriebenen. Das will auch keiner hören, also wird das Ganze so lange umformuliert, bis es in einer völlig verwässerten Form im Protokoll landet. Am Ende bekommt der Admin als letztes Glied der Kette irgendeine vollkommen hirnrissige Aufgabe aufgedrückt, die ihn wochenlang damit beschäftigt, ein sinnleeres Dokument, dabei seine eigentlichen Aufgaben zu vernachlässigen und schließlich zuzusehen, wie das fertige Dokument im Sammellaufwerk Staub ansetzt. Das soll ihn leeren, noch einmal die kuschlige Eintracht der Nachbetrachtungssitzung mit aufmüpfigen Kommentaren zu besudeln.

Schlussbemerkung - oder: Wo es nichts zu managen gibt, braucht man auch keinen Manager.

Was Sie hier gelesen haben, erzählt man Ihnen auch in jedem Projektleitungsseminar. Es ist also allgemein bekanntes Wissen. Warum wird es in der Praxis so beharrlich ignoriert? Ehrlich gesagt: Ich verstehe es auch nicht. Einer der Gründe kann sein, dass man selten in Führungspositionen landet, weil man dorthin gehört, sondern weil man beispielsweise der Firmengründer ist, der aus der Hinterhofklitsche mit viel Hemdsärmeligkeit und Pioniergeist ein mittelständisches Unternehmen formte, nun aber an der Aufgabe scheitert, in der einsetzenden Kosolidierungsphase Ordnung in den Laden zu bringen. In Großunternehmen wiederum geraten viele Leute in Führungspositionen, weil sie die entsprechenden Seminare besucht und brav ihre Zertifikate gesammelt haben. Nun wird man durch das Besuchen von Managerseminaren genauso wenig Manager wie man durch das Studium der Aerodynamik zum Vogel wird. Verschärfend kommt die in vielen Unternehmen herrschende Vorstellung hinzu, Manager werde man als Belohnung für gute Tätigkeiten, und Management sei ein generischer Vorgang, der nicht großartig unterscheide, ob man nun eine Internetplattform oder eine Stahlfabrik verwalte. Als Ergebnis werden großartige Techniker in Leitungspositionen gehievt, wo sie zuallererst ihr in jahrzehntelanger Arbeit angesammeltes technisches Wissen komplett vergessen müssen, um sich künftig ganz dem Ausfüllen von Exceltabellen zu widmen. So vernichten DAX-Unternehmen Jahr für Jahr die Kenntnisse, die nötig wären, um den Laden am Laufen zu halten, nur um ihren ohnehin schon kolossalen Wasserkopf weiter aufzublähen. Dieser wiederum ist sich seiner eigenen Redundanz durchaus bewusst und versucht die Illusion von Wichtigkeit zu erzeugen, indem er die Firma jährlich einer Reorganisation unterzieht, die in erster Linie Geld verbrennt, Unruhe erzeugt und genau in dem Moment durch die nächste Reorganisation abgelöst wird, in dem die Maßnahmen zu funktionieren beginnen. Das verloren gegangene Wissen wiederum muss wieder herangeschafft werden, also kauft man sich Externe, die zwar dieses Wissen besitzen, aber es nicht teilen. Dennoch hält diese Maßnahme die Firma am Leben, was die Verantwortlichen veranlasst, mit der Symptombekämpfung auch die Ursachenbehebung als abgeschlossen zu betrachten und sich nun der Frage zu widmen, wie man die gestiegenen Externenkosten senken kann. Die Antwort lautet - na? - Interne feuern, genau, wodurch noch mehr Wissen vernichtet wird, das man sich wieder extern einkauft - hat ja schon einmal prima funktioniert.

Die eine, große Idee, mit der sich dies alles korrigieren ließe, gibt es meiner Ansicht nach nicht, aber vielleicht hilft es ja, sich die Kapitelüberschriften ab und zu in Erinnerung zu rufen.