Zurück zum Blog

Bazar – Der etwas andere Marktplatz

Stellenbeschreibung „Feuermelder“

IT-Weisheit:
In der Implementierungsphase verursacht jede falsch oder nicht identifizierte Anforderung bereits sechsmal so hohe Kosten wie zu Projektbeginn.

Schon wieder höre ich es, diesmal hier ganz aus der Nähe: Eine Software-Umstellung zieht und zieht und zieht sich. Erinnert mich an einen Brillenkauf vor Jahren, als mir der Optiker erzählte, sein Lieferant könnte wegen desselben Software-Hauses keine Brillen vom Lager liefern, sondern müsste sie einzeln nach Anforderung herstellen. Dies zog die Lieferfristen in die Länge und füllte die Läger, ich arbeitete jedoch damals schon in der Branche und war deshalb großzügig gestimmt, so „unter Kollegen“.

Bei dieser Firma jetzt ist es freilich etwas Besonderes. Sie ist deutsche Geschichte.

Der ländliche Raum hier ist trotz seiner Idylle und seiner kleinbürgerlichen Atmosphäre voller Geschichte: König Löwenherz soll im Trifels gefangen worden sein, Worms ist die älteste freie Stadt Deutschlands, Gutenberg druckte die erste Bibel und Berta Benz fuhr ihre berühmte Fahrt 1888 von Mannheim nach Pforzheim, mit Apotheken als Tankstelle.

Carl Benz, der trotz seiner Energie und seiner technischen Fähigkeiten ständig um Geld kämpfen musste, hat dieses Erbe wohl irgendwie seiner Firma hinterlassen. Und nun kämpft sie mit der Software-Umstellung, besser gesagt, ihre Mutter kämpft damit, denn Carl Benz’ Firma ist schon lange nicht mehr selbstständig. Doch sie existiert noch. Längst nicht mehr „topaktuell“ in den Räumlichkeiten, fast heruntergekommen, gibt es trotzdem immer noch das Tor, von dem aus Berta Benz startete.

Und nun können sie seit drei Monaten keine Rechnungen bezahlen. Die Anrufe der Lieferanten werden schon bissig, richten sich an immer höhere Positionen, die Mahnungen stapeln sich – die einzige Hoffnung (nach drei langen Monaten) ist die Tatsache, dass jeder weiß, dass Software-Umstellungen schon mit dem Tode der Kundenfirma geendet haben und dass die meisten Lieferanten das nicht wirklich wollen.

Warum?

megalomania is the shortest path to defeat
Größenwahn ist der kürzeste Weg zur Niederlage

Oh, obwohl ich die Selbstgefälligkeit der Berater, die ich viel, viel zu oft in meiner langen Laufbahn erleben musste und als eine bedeutende Ursache der meisten Fehlschläge festgestellt habe, nicht ausschließen will/kann, gibt es auch andere Quellen für Misserfolg.

Auch Kunden können Dinge falsch machen.

- Sie „denken“ sich etwas, halten Funktionen für selbstverständlich, weil sie ihnen seit Jahren geläufig sind und vergessen, dass jede Firma irgendwo auch ein Individuum ist, ganz besonders im Mittelstand (Scheuklappenfaktor). Standard-Software deckt freilich nur die Bedürfnisse der Allgemeinheit ab. Eine interessante Variante davon ist auch, dass Kunden gelegentlich ihre eigene Terminologie haben, sie nennen Dinge anders, als es die meisten anderen tun. Jedes Software-Haus ist dann darauf angewiesen, dass seine Leute aufmerksam genug sind, die Widersprüche in den Inhalten der Homonyme rechtzeitig zu entdecken und aufzuklären.

- Sie wollen „billig“ davonkommen, soll heißen, es soll nichts kosten, weder an Arbeit noch an Geld (Futterneidfaktor). Sie neigen dann dazu, den (falschen) Beratern zu glauben, die ihnen Null Probleme versprechen, und je großartiger die Berater auftreten, umso glücklicher sind die Kunden. Wer will denn von Schwierigkeiten hören, die nur aufhalten und teuer sind? Doch wie sollte eine Standard-Software, die für einen „allgemeinen“ Fall erstellt wurde, ohne jegliche Änderung für den individuellen Einzelfall gelten können? Und für manche Katastrophen „danach“ reichen ein paar kritische Abweichungen, die die Software nicht oder anders handhabt, als die Kunden es brauchen würden, um deren Betrieb empfindlich stören oder gar lahm legen zu können. Das ist auch schon passiert.

- Sie sind zu unerfahren und folgen deshalb der Herde. Anstatt das für sie beste Produkt zu kaufen, nehmen sie das, was die meisten anderen nehmen: „Da kann man nichts falsch machen“ (Lemmingsfaktor). Niemand wird so von allen Seiten gejagt wie ein Projektleiter, der es wagte, ein „Nicht-Standard-Produkt“ ins Auge zu fassen und damit Probleme zu bekommen.

- Sie unterschätzen den Einschnitt. Sie haben alle schon PC-Programme installiert, manche sogar kleine Netze und verwechseln eine Firmensoftware, die die Betriebsabläufe steuern soll, mit einem Programm, das sich von CD installieren lässt und fertig. Solche Programme können sehr komplex sein, das ist nicht die Frage (Eclipse). Es ist nur – huhu, praktisches Beispiel Informationstheorie! – dieselbe Unterscheidung wie zwischen Sackgassenkomponente und komplexer Komponente oder auch zwischen Variable und Handlungsträger/Rolle/Task/mighty class (Sprachgebrauch der ML-Methode), die sich an der Abhängigkeit vom Problem, der Aufgabe aufhängt:

Die Fliege oder Das Handwerk der Datenbank-Programmierung, Objekt: Handlungsträger kontra Variablentypus:
Variable:
ist eine Sammlung von Methoden mit ihren Variablen nur von einem eigenen zentralen Input abhängig, so ist sie unabhängig von jedem Problem und vor allem, von jedem möglichen Zustand des Problems, und kann unbekümmert angewendet werden.
Handlungsträger:
ist eine solche Kollektion von Methoden und Variablen jedoch in der Lage, bei Bedarf selbst auf andere “Sammlungen” zurückzugreifen oder sich selbst aus Datenbanken aktuelle Informationen zu besorgen, so ist sie keinesfalls unabhängig vom Problem und seinem akuten Zustand. Dann sollte sie auf keinen Fall mehr als an einer einzigen Stelle vorzufinden sein.

Programme, die von vielen Leuten einheitlich verwendet werden wie Programmierumgebungen, Textverarbeitungen oder Tabellenkalkulationen, können so kompliziert sein wie sie wollen, sie drehen sich um eine klar definierte Aufgabe und sind darauf optimiert. Ihr „einziger Input“ sind die Personen, die sie anwenden, deren Vorgaben sie höchstens gegen ein paar eigene Speicherdaten prüfen. Werden sie installiert, so wissen sie längst, welche Dinge vielleicht anzupassen sind und fordern sie an.

Programme, die wie Firmensoftware Betriebsabläufe steuern sollen, müssen diese abbilden können. Sie werden nicht nur von Personen gefüttert, sondern von allen möglichen anderen „Eingangsstellen“, sie müssen nicht nur gegen eigene Datenbanken prüfen, sondern sich immer häufiger auch mit anderer Software „unterhalten“ – Stichwort RTE. Sie können unmöglich vorher wissen, wie die Betriebsabläufe im Einzelnen tatsächlich aussehen, sie können sich nur nach Durchschnitten richten und müssen deshalb für jede Firma fein justiert werden. Solange es kleine Firmen sind, die nur Teile ihrer Abläufe mit Software unterstützen, kann es ausreichen, dass die Firma sich an die Software anpasst – je mehr Bereiche des gesamten betrieblichen Lebens jedoch von der Software abgedeckt werden, umso unwahrscheinlicher wird es, dass die Firma sich noch an die Software anpassen kann. Wobei die Frage offen bleibt, ob das wirklich immer zu empfehlen ist.

Unterschätzung dieser Problematik hat Leichtsinn zur Folge: Die Kunden, die zumeist im Tagesgeschäft schon genug zu tun haben, kümmern sich nicht ausreichend um ihre Pflichten, sie prüfen die Dokumente, die vom Software-Haus zur Klärung von Fragen verfasst werden, nicht genau genug nach, sie testen nicht gut genug, sie verlassen sich eben einfach drauf, dass es schon gut gehen wird – zusammen mit Futterneidfaktor, Lemmingsfaktor und Scheuklappenfaktor fühlen sie sich wohl und zufrieden, weil alles so schön billig ist, weil die Software von sooooo vielen anderen auch installiert wurde (von deren Schwierigkeiten sie natürlich nichts hörten) und weil alles, was sie gesehen haben, so herrlich bunt und vollkommen aussah, genau wie der Berater, der alles so perfekt im Griff hat und immer so cool daherredet (Blenderfaktor).

All diesen „unguten“ Faktoren versuchte ich immer, zumeist erfolgreich, entgegenzutreten, auch wenn all diese Faktoren spiegelbildlich ebenso bei den Software-Häusern vorliegen.

Scheuklappenfaktor:

Es gibt nur zwei Sorten von Beratern, die unerfahrenen und die erfahrenen. Die unerfahrenen können’s nicht wissen, die erfahrenen wollen’s oft nicht. Denn die Erfahrenen wissen alles schon, ha’m alles schon gemacht, kennen sich aus – brauchen nicht so genau nachzufragen, brauchen nicht so genau zuzuhören, wissen längst im Voraus, was los ist.

Futterneidfaktor:

Natürlich möchte jedes Software-Haus soviel Gewinn als möglich herausschlagen aus einem Projekt, also muss sowenig wie möglich Arbeit hineingesteckt werden. Wenn darüber hinaus die Kalkulation noch eng war (und immer enger wird), sinkt die „Lust“ an zusätzlichem Aufwand noch weiter ab.

Blenderfaktor:

Auch das Software-Haus leidet unter dem Blenderfaktor. Zwar wissen die Verantwortlichen, dass ihr Produkt längst nicht so prächtig ist, wie es die Vertriebsleute hinstellen, doch sie beruhigen ihr Gewissen gerne mit dem Satz „die anderen kochen auch nur mit Wasser“. Und den Kunden genügt’s ja, sonst hätten sie es wohl nicht gekauft. Deshalb hören sie, genau wie die Kunden, viel lieber auf Projektmitarbeiter, die ihnen erzählen, wie toll alles läuft als auf solche, die warnen, dass etwas schief gehen wird. Karriere macht nur der, der „alles im Griff“ hat, nicht der, der Probleme sieht und sie teuer lösen möchte, bevor es knallt. Denn natürlich lieben auch die Kunden die bunten Paradiesvögel mehr als Schaffer, die zumeist noch etwas von ihnen wollen, Prüfungen, Klärungen, Tests, Änderungen, Zeit, Geld...

Und wenn es zur Katastrophe kommt und der prächtige Kerl in wochenlangen Überstunden das Schiff vor dem Untergang rettet, dann sind sie sogar noch dankbar und loben das Engagement und die Tatkraft, während sie bei Installationen, die sauber vorbereitet sind, über jedes kleine Problem jammern und am Ende die „ständigen Schwierigkeiten“ beklagen.

Tatsache.

Ich schätze, das liegt einfach an der Schmerzgrenze. Eine saubere Installation ist wie eine sanfte Musik, bei der jeder Misston übel aufstößt – eine Katastropheninstallation ist ein totales Crescendo, das dir die Sinne mit seiner misstönenden Lautstärke nimmt und bei dem jedes kleinste Nachlassen eine wahre Erleichterung ist.

Lemmingsfaktor:

Der Lemmingsfaktor, der Gleichschritt unbekümmert der individuellen Unterschiede, herrscht auch im Software-Haus. Besonders unerfahrene Berater müssen sogar so handeln, einfach weil ihnen gar nichts anderes übrig bleibt als es so zu tun, wie es die anderen tun. Andererseits neigen erfahrene Berater auch dazu, ihren eigenen Trott beizubehalten, unabhängig vom aktuellen Projekt und manchmal ist es sogar Pflicht, weil das Software-Haus irgendwelchen Qualitätsstandards folgt. Diese sind manchmal doch nicht so tauglich, wie es die Qualifizierer gerne behaupten, zumal wenn sie zu wenig auf der „Metadaten-Ebene“ formuliert sind und zu tief in die Details gehen. Denn die Details eines nur mittelgroßen Projektes lassen sich bereits nicht mehr exakt festschreiben, Kunden sind schließlich Firmen. Einzelne Menschen sind schon kompliziert genug - in einer Gruppe werden sie nicht notwendig einfacher.

Nun, ist es da noch ein Wunder, wenn so viele Software-Projekte schief gehen? 80% sollen ihre Ziele nicht einhalten, weder in Funktionalität noch Budget, manche mehr, manche weniger.

Diese Berta-Benz-Firma jedoch dürfte fast ein „manche mehr“-Fall sein, denn drei Monate seine Rechnungen nicht bezahlen zu können, ist ein Fall, der ohne Software-Installation den Insolvenz-Verwalter erfordert. Mahnungen, Gerichtsvollzieher werfen immer Schatten in der Schufa und damit auf die Einstellung der Banken und Lieferanten zu dir, das kann haarig werden.

Das kann an die Existenz der Firma rühren, wenn sie nicht verdammt schnell ihre Schulden begleichen können und es wäre sicher nicht der erste Todesfall auf der Abschussliste großer Software-Häuser. So was kommt schließlich vor, nicht wahr? Eine große amerikanische Beraterfirma musste sich sogar umbenennen, um der Vergangenheit zu entkommen, soweit kam es bisher doch noch nie, was also soll so schlimm dran sein? Es ist nun mal eine komplexe Arbeit.

Stimmt alles.

Und dennoch zeigen Missstände auch ihre Lösungen auf.

Bei einem der weniger glücklichen Projekte, an denen ich beteiligt war, bei dem sich nach langer Zeit gemächlicher und sauberer Arbeit auf einmal Rahmenbedingungen veränderten, die wir erst später erfuhren, sollten plötzlich unbeachtlich jeder Gegebenheit Termine eingehalten werden, die kaum machbar waren – politisch bedingt, wie es in größeren Firmen nun mal vorkommt.

Ich war besorgt, denn ich konnte die Ursachen der Veränderung nicht ausmachen, sah nicht, wieso die Mitarbeiter des Kunden distanzierter, gar aggressiver wurden. Mir war zwar klar, dass die internen Machtspielchen sich nicht günstig auf das Projekt auswirkten, mir war auch klar, dass die neuen oder externen Mitarbeiter mit ihren Aufgaben oft völlig überfordert waren und deshalb einen Sündenbock suchten, doch ich konnte es nicht in Reaktion umsetzen. Es war nämlich schlicht und einfach „nicht meine Sache“, es drehte sich nicht um meinen Aufgabenbereich – es „ging mich nichts an“.

Warum ich dann den Fehler machte, mich einzumischen und damit Angriffsfläche zu bieten?

Weil ich einen sauberen Job liefern will, auch im Team – und weil ich Dinge genauer sehen kann als andere. Ich besitze einfach mehr Allgemeinwissen, habe mehr erfahren, eben auch Probleme und, ganz wichtig, ich bin selbstkritisch, ich gebe Fehler zu. Das ist an sich schon der größte Fehler, den du überhaupt tun kannst – abstreiten ist angesagt, Sündenbock suchen, wissen wir alle.

Andererseits frage ich mich: wozu?

Wie sehr muss ich mich verbiegen, verleugnen, verraten für all die „Kohle“, die mir als Belohnung winkt? Nun, ich stamme aus „asozialen“ Kreisen, mein Vater war Alkoholiker, meine Mutter Flüchtling aus gutem Hause, die nach dem Krieg praktisch betteln musste. Ich habe ganz andere Prioritäten als andere Menschen – ich kann in Lumpen in die Vorlesung „Funktionalanalysis“ gehen und genau wissen, dass ich damit niemals Erfolg haben werde – und glücklich und zufrieden sein.

Soviel dazu.

Ich konnte also gar nicht anders, als die Schwierigkeiten, die sich im Teilprojekt meines Teams aufzuhäufen begannen, nicht nur zu sehen, sondern auch zu kommunizieren. Der Leichtsinn und die Selbstzufriedenheit nahmen mir jedoch völlig den Wind aus den Segeln, denn ich mochte mein Team, seine Freundlichkeit, seine Intelligenz, seinen Charme – und eigentlich ging mir seine Anerkennungsgier nie wirklich auf die Nerven, auch wenn das große Auto, das endlich jedem auf der Straße demonstrierte, „dass es hier jemand geschafft hat“, mir einige Illusionen raubte.

Zurück zu den Problemen des Projektes: Meine Reaktion wäre gewesen, manche Aufgaben von den Leuten zu übernehmen, für die sie eben nicht kompetent genug waren. Das ging natürlich gar nicht von Kundenseite her, weil es zuviel Geld kostete (Futterneidfaktor), erst recht nicht für meine eigene Chefetage – und dann funkte ja mein Team noch dazwischen, das alles perfekt im Griff hatte, das keine Probleme sah, weil es die Herausforderung des großen Projekts als Karriereschub sah und um keinen Preis den Anschein des „Erfolgreichen“ riskieren wollte, (dem deshalb vielleicht gar keine Veränderung beim Kundenverhalten auffallen durfte,) das glücklich war, so tolle Arbeit vorführen zu können und, tja, endlich große Dienstwagen zu fahren (Blenderfaktor).

Das Team hatte die Sache so wunderbar im Griff, dass es in der heißen Phase in Urlaub zu fahren imstande war, weil seine schwangere Frau noch mal auf die Pauke hauen wollte, solange sie noch „hübsch schlank“ war – eigentlich eine Undenkbarkeit, doch da die Chefetage gerne glaubte, dass alles prächtig verlief und, man glaubt es kaum, auch der Projektleiter der Kundenfirma um diese Zeit in Urlaub ging, wurde es bewilligt.

Nach fünf bis zehn Minuten Briefing musste ich deshalb die Programme des Teams übernehmen, die ich im Standardfall natürlich kannte. Es war freilich ein interessantes kleines Teilprojekt dabei, das ich lange hatte an den Mann bringen wollen, weil es viele unsinnig untergebrachte, sachlich indessen wichtige Modifikationen auch aus meinem Verantwortungsbereich fokussierte auf eine schöne, kleine, übersichtliche Stelle und damit eine mächtige Schaltstelle für die gesamten Abläufe der Firma bot. Ich musste jedoch erst mein Team einschalten (das alles so perfekt im Griff hatte), damit endlich kurz vor Torschluss die Kunden dem „teuren“ Teilprojekt zustimmten. Oh, es war nicht „der tolle Berater“ alleine! Es war schlicht und ergreifend unübersehbar geworden, dass die vielen Modifikationen nicht mehr realisierbar waren, es war nicht mehr zu leugnen, dass das ganze Projekt gefährdet sein könnte und dieser Schmerzpegel genügte, um Geld locker zu machen. Ich war zufrieden damit, weil es eine spürbare Verbesserung darstellte, auch wenn es nicht „mein Karriereschub“ war.

Natürlich flog das Ding völlig auf die Schnauze, weil die Anerkennungsgier mein Team dazu trieb, dem Boss noch gefälliger zu werden durch immer mehr Projekte, die es „toll im Griff“ hatte und deshalb schlicht nicht genügend Zeit für sorgfältige Arbeit und Test aufbrachte – und auch, weil Anerkennungsgier zumeist mit Selbstüberschätzung und damit fehlender Selbstkritik einhergeht. Welches Genie muss schon seine eigene Arbeit kritisch betrachten?

Und ich? Ich kritisiere zwar mich, doch nur im Rahmen andere – blöde Mischung, ich weiß. Ich hatte meinen Job so sauber gemacht, wie es mir möglich war und „nebenbei“ versucht, meinem Team die mir offenkundigen Probleme klarzumachen. Manchmal schien es zu glücken, manchmal nicht, doch die Verantwortung trug letztendlich nicht ich, sondern das Team. Und da es kein schlechtes, höchstens ein leichtsinniges Team war und ich Kollegen nicht in den Rücken fallen mag, blieb mir kaum mehr als „Cassandra“ zu spielen. Andererseits muss ich zugeben, dass ich eine Form von Frust fühlte und vielleicht deshalb dazu neigte, das neue Teilprojekt nicht unbedingt auswendig zu lernen.

Das aber hätte ich tun müssen.

Als das kaum getestete Programm ständig gegen die Wand fuhr, wusste ich oft nicht einmal, was es eigentlich korrekt hätte tun sollen. Ich hatte zwar dauernd davon gehört, wie toll die Programmierung des Projektes war und wie genial mein Team alles hingekriegt hatte, doch so etwas wie eine umfassende Dokumentation gab es nicht. Und so hatte ich, neben meiner Arbeit, nicht den Überblick, die „Rettungsaktionen“ rasch und zügig genug durchzuführen. Bei einem aggressiven Kunden muss das nämlich richtig rasch und zügig sein, Einarbeitung ist nicht drin.

War ein echter Karriereschub für mich seinerzeit – nur leider nach unten.

Damals bat ich einen Kollegen mit ruhiger, souveräner Ausstrahlung, die Sache nach außen zu übernehmen. Er hatte zwar ebenfalls keine Ahnung vom Programm, war sogar stolz darauf, „den Kopf freizuhaben“ von Programmierkenntnissen, sodass er sich völlig aufs „Beraten“ konzentrieren konnte, aber das war mir in dem Moment egal. Ich brauchte jemanden, der Wogen glätten konnte – und da er nichts mit dem Projekt zu tun hatte, konnte er ruhig bleiben bei den Angriffen, konnte den Kunden Recht geben, konnte moderieren und beruhigen. Und es funktionierte.

Warum ich das erzähle?

Nein, ich will kein Mitleid heischen – und ja, wenn du mich als Lusche und Totalversager sehen willst, bleibt es dir überlassen. Ich habe mich damals nicht durchgesetzt, obwohl ich genau wusste, was kommen würde und auch gewusst hätte, wie es zu vermeiden sei.

Ich hätte seinerzeit einfach tun müssen, was ich für richtig hielt – die Sturheit gegenüber meinem Boss und meinem Team hätte ich problemlos aufgebracht, die Kompetenz hätte ich gehabt, ich hätte es also sehr wohl machen können.

Und das macht es tatsächlich wenigstens teilweise zu meinem Fehler, dieses Projekt, das für die ganze restliche Zeit der Kundenbeziehung die Atmosphäre vergiftete...

Ich hätte es jedoch nur tun können, wenn ich Arbeit aus dem Zuständigkeitsbereich meines Teams übernommen hätte, wenn ich seine fehlende Sorgfalt deutlich gemacht hätte.

Und das brachte ich nicht fertig.

Und schon sind wir bei der Stellenbeschreibung „Feuermelder“:

Genau deshalb müssen „Feuermelder“ Außenseiter sein. Das verhindert all diese projektfeindlichen Sym- und Antipathien und es verhindert den Futterneid, weil das Projekt nur indirekt der Karriere (und damit dem Geldbeutel) förderlich ist. Indirekt? Weil nur über die Statistik ein Hinweis auf die Arbeit der Feuermelder möglich ist: Schaffen sie es, mehr Projekte erfolgreicher zu gestalten als zuvor, sind sie gut, ansonsten überflüssig.

Und es verhindert die Auswirkung des Blenderfaktors auf das Projekt. Ja, sicher war mein Kollege, den ich seinerzeit als „Ausgleich“ eingeschaltet hatte, ein eher noch stärkerer Blender als mein Team. Oft genug beruhigte er die Kundenmitarbeiter nur mit dem Zugeständnis von Fehlern – waren ja nicht seine. Sein Ton, der die Kunden so besänftigte, war dabei eine interessante Mischung von Verständnis (für die Verärgerung der Gegenseite) und Unverständnis (für die „unentschuldbaren“ Fehler des Teams). So wirkte sich der Blenderfaktor positiv auf das Projekt aus, denn hier war Ritter Eisenherz angesagt, der Retter in der Not.

Was er auch noch demonstrierte: Feuermelder müssen gehört werden. Mein Kollege war nicht nur ruhig und souverän, (was ich persönlich oft schlicht als langsam empfand), er war auch trotz fehlender Software-Kompetenz ein sehr zielstrebiger Karrierist. Oh, er war nicht unser Chef – das hätte den ausgleichenden Effekt auch völlig zerstört, er war nur dabei, vielleicht mal unser Chef zu werden.

Warum es den Effekt zerstört hätte? Weil Chefetagen Machtspielchen spielen und weil sie primär am Ertrag des Projekts interessiert sind, nicht am Projekt selbst. Nicht nur dieses Projekt hatte des Öfteren schon die selbstgefälligen Sprüche „wir unter uns“, großmütig von Chef zu Chef über die streitenden Untergebenen hinweg, erdulden müssen und es hatte nichts bewegt. Wenn der Boss wie Donnergott Thor zürnt und Blitze wirft, ändert das kein einziges Statement im Programm.

Ja, sicher gibt es Ausnahmen und ja sicher könnten das dann gute „Feuermelder“ sein – aber es ist eben nicht die Regel und eine Stellenbeschreibung sollte sich tunlichst nicht an Ausnahmen orientieren.

Also zurück zum „gehört werden“: Feuermelder müssen also mit Zuständigkeiten ausgestattet werden – freilich ohne sie ins Projekt zu verwickeln.

Schwierig.

Nun gut, Vorschlag: Feuermelder müssen Konferenzen einberufen können zwischen den Projekt-Partnern, sie müssen die Gelegenheit erhalten, mit genau den Leuten zu reden, die sie sich aussuchen, auch wenn es die Arbeiter im Lager sind, die Null Ahnung von Programmierung haben, sie müssen Berichte anfordern dürfen und Projektstati. Zu letzterem muss es auch gehören, dass vom Feuermelder festgestellte Fehler bei einem späteren Treffen hinsichtlich ihrer Berücksichtigung/Beseitigung von beiden Seiten, Software-Haus und Kundenteam, eingefordert werden dürfen (Feuermelder-Rapport).

Sie sollten freilich nicht den Fehler machen, die Arbeit zu beaufsichtigen und sie sollten nicht den Fehler machen, sich in die Arbeit einzumischen. Dadurch ginge ihnen nur die Distanz verloren, die sie brauchen, um Blender- und Futterneidfaktor auszuschalten. Deshalb müssen sie bei Diskussionen über das „Wie“ nicht sofort mundtot werden, sie müssen sich jedoch sehr kontrollieren, nicht zu bevormunden.

Sie müssen also scharfe Beobachter sein, fähig genug, sich rasch in die Probleme einzuarbeiten, aber auch zurückhaltend genug, um nicht Verantwortung an sich zu reißen, die besser bei anderen bleibt.

Warum?

Weil die Projektmitarbeiter selbst kompetent sind. Sie tun ihren Job und sie tun ihn meistens richtig gut, da beißt die Maus keinen Faden ab.

Aber ein Laufrad hat nun mal seine Tücken, egal wie fleißig der kleine Hamster darin ist – und diese Tücken sollen Feuermelder besiegen, nicht die Probleme des eigentlichen Projektes.

Sie müssen Schwierigkeiten erkennen können, die andere, aus welchen Gründen auch immer, nicht sehen können oder wollen, sie müssen sie ihrem Gefahrenpotential nach einstufen können und sie müssen dabei psychologisch geschickt vorgehen, weil sie dem Projekt nicht dienen, wenn sie die Leute noch mehr aufheizen. Deeskalation ist in solchem Fall angesagt, der Abbau von Energie nur für eigene Verteidigung, um sie stattdessen wieder in das Projekt stecken zu können.

Alleine diese Beschreibungen (Beobachter, nicht bevormunden, Deeskalation) schalten freilich viele Leute aus – alle, die dem Blenderfaktor folgen, beispielsweise.

Doch nur auf den ersten Blick, man denke an meinen Kollegen!

Wer Feuermelder gut bezahlt, an statistischen Verbesserungen von Projektergebnissen beteiligt und sogar eine ganze Gruppe von ihnen ermöglicht, die wie die Schimpansenhorden „auf Kriegspfad“ in fremden Revieren wildern darf, der kann auch Blender prächtig dazu verwenden. Du musst es nur fertig bringen, dass Deeskalation, Nicht-Einmischung, gute Beobachter „Pluspunkte“ werden, mit denen sich angeben lässt...

und schwupps...

hast du gewonnen. Schließlich gibt es in den meisten Firmen und Behörden Kontrollorgane wie die Rechnungsprüfung, der Unterschied zum Feuermelder ist jedoch genau der zwischen Menge und Information: Mengen werden aus Information a posteriori aufgestellt, während Entscheidungen auf a-priori-Wissen basieren müssen, auf der Informations-Vermutung, auch wenn sie noch so unsicher ist. Kontrollorgane, die hinterher Fehler aufdecken, sind unbezweifelbar unersetzlich, weil die Missstände dann realisiert wurden, „wahr“ wurden und nicht mehr nur „befürchtet“ werden und weil ihre saubere Protokollierung den Lerneffekt unterstützen kann. Andererseits – helfen sie eben dem aktuellen Projekt nicht mehr, Geld zu sparen. Dann tritt freilich, wie bei der Euro- oder Y2K-Umstellung, der „ungünstige“ Tatbestand auf, dass ein Schaden nicht eintrat und somit alles, was seiner Vermeidung diente, als „unnütz teure“ Vorarbeiten angesehen wird – wo man prächtig „sparen“ und „downsizen“ kann. Dass Schadensvermeidung immer und überall viel, viel billiger ist als Schadensbegrenzung, verstehen wohl einfach die wenigsten (Assoziation Umweltschutz?).

Ok, gut.

Zwei Punkte sind noch offen: der Lemmingsfaktor und der Scheuklappenfaktor.

Nun, alleine die Außenseiterposition verhindert beides, ganz automatisch.

Wie?

Feuermelder dürfen sich nicht in die Arbeit einmischen, also werden sie nie während des gesamten Projektes gebraucht, sie „besuchen“ die Projekte nur zeitweise, um ihren Verlauf zu beschnuppern und „Feuer zu melden“, dann wechseln sie die Bühne und begutachten das nächste Projekt: Sie sind typische Springer, deshalb brauchen sie auch die rasche Auffassungsgabe. Wenn sie also Lemminge sind, dann müssen sie es auf einer solch hohen Meta-Ebene sein, dass es ihre schnelle Anpassung an die diversen Projekte nicht gefährdet. Und einen Scheuklappenfaktor können sich Feuermelder ebenfalls nicht erlauben wegen der Wechselhaftigkeit der Projekte – zumindest nicht lange. Wollen sie ihren Job behalten, müssen sie die Augen offen halten und dürfen keinerlei Verdrängungswünschen nachgeben.

Und sie müssen kreativ sein und ihre Ideen auch dann noch realisieren können, wenn sie in der Vergangenheit nicht immer funktioniert haben.

Warum ich gerade das schreibe?

Weil ich mir oft genug wünschte, bei Kunden, die das Projekt unterschätzten und es deshalb schleifen ließen, auch zu ungewöhnlichen Maßnahmen zu greifen. Ich hätte frühere Fehlschläge als Abschreckungsbeispiel verwendet: „Aus Fehlern wird man klug“. Soll heißen, ich hätte die Kundenmitarbeiter, die „etwas Wichtigeres“ zu tun haben, geschnappt und zu ihren Vorgängern geschleift, damit sie deren Frust und Zorn so richtig zu spüren bekommen. Ich habe oft genug „Feuerwehr“ gespielt, um das mitzubekommen – es wirkt abschreckend, jede Wette.

Doch – das verletzt natürlich den Blenderfaktor.

Denn ein Software-Haus muss zugeben, Fehler gemacht zu haben oder wenigstens enorme Probleme bekommen zu haben, nix mit „toller Berater“. Andererseits denke ich, dass es die Partnerschaft zwischen beiden Parteien verbessert und letztendlich den Respekt voreinander fördert. Alle machen Fehler – aber nur die, die sie weder vertuschen noch auf die leichte Schulter nehmen, können sie als Lehrmaterial verwenden, um die Qualität der eigenen Arbeit zu steigern.

Professionelle Bezeichnung

Eine der marktgängigen Bezeichnungen, die wohl für eine vergleichbare Stellenbeschreibung verwendet wird, ist „Escalation Manager“, doch inwieweit genau sich beide Profile überschneiden? Schwer zu sagen, nachdem professionelle Stellenbeschreibungen selten in einfacher Umgangssprache formuliert sind.

Kurze Zusammenfassung „Feuermelder“

Projekt-Außenseiter:

Distanz = keine Einmischung in die eigentliche Projektarbeit

Kompetenzen:

Gehört werden = Anforderung von Konferenzen, Gespräche, Berichten, Feuermelder-Rapport

Ungewöhnliche Maßnahmen = Tarnen & Täuschen, Überreden & Überzeugen

Profil:

Beobachter = Aufmerksamkeit, Gefühl für Zwischentöne

Sachverstand = rasche Einarbeitung in auch fremde Fachgebiete als Voraussetzung dafür, dass Schwierigkeiten nicht nur erkannt, sondern ihrem Gefahrenpotential gemäß eingestuft werden können (Springer)

Deeskalierende Persönlichkeit = Moderation, nicht Bevormundung

Kreativität = Auffinden von ungewöhnlichen, Erfolg versprechenden Maßnahmen.

Pluspunkte:

Gehalt: muss mindestens dem eines Abteilungsleiters entsprechen, da der Job seine Risiken aufweist bei gleichzeitig hohen Anforderungen

Provision: es sollte eine Projektbewertung vorgenommen werden, die aussagekräftige Statistiken ermöglicht, sodass der „Vermeidungserfolg“ durch eine abflauende Misserfolgskurve nachweisbar wird. An diesem Abflauen sollten Feuermelder beteiligt sind (s. Blendereffekt)

Zurück zum Anfang

© bussole IV 2004 (außer Zitate)

Zurück zum Blog