Prinzip Arche Noah – Nicht perfekt, aber rechtzeitig!

Stellen Sie sich vor, die Sintflut steht bevor und Sie brauchen eine Arche. Wen nehmen Sie als Projektleiter? Einen Schiffsbauer mit zoologischem Zusatzstudium? Gott wählte einen Bauern. Noah hatte kein Fachwissen, aber Erfolg. Eine ähnliche Erfahrung machte unser Autor, als er bei einer krisengeplagten Großbank ein brisantes IT-Projekt leiten musste – ganz ohne IT-Fachwissen. Was zunächst als großes Defizit erschien, entpuppte sich als seine Rettung. Klaus Schuster und sein Co-Autor Klaus D. Tumuscheit beschreiben, welche Vorteile es haben kann, wenn ein Projektleiter nicht auf Fachwissen bauen kann, sondern sich ganz auf sein PM-Know-how verlassen muss.

 

Prinzip Arche Noah – Nicht perfekt, aber rechtzeitig!

Stellen Sie sich vor, die Sintflut steht bevor und Sie brauchen eine Arche. Wen nehmen Sie als Projektleiter? Einen Schiffsbauer mit zoologischem Zusatzstudium? Gott wählte einen Bauern. Noah hatte kein Fachwissen, aber Erfolg. Eine ähnliche Erfahrung machte unser Autor, als er bei einer krisengeplagten Großbank ein brisantes IT-Projekt leiten musste – ganz ohne IT-Fachwissen. Was zunächst als großes Defizit erschien, entpuppte sich als seine Rettung. Klaus Schuster und sein Co-Autor Klaus D. Tumuscheit beschreiben, welche Vorteile es haben kann, wenn ein Projektleiter nicht auf Fachwissen bauen kann, sondern sich ganz auf sein PM-Know-how verlassen muss.

 

War Noah Schreiner? Nautiker? Zoologe? Keines von den dreien. Er war Bauer. Also fachlich im Grunde vollkommen ungeeignet für das Großprojekt "Rettung der Menschheit vor der Sintflut". Und trotzdem ernannte ihn Gott zum Projektleiter. Ein menschlicher Auftraggeber hätte niemals Noah, sondern einen Schiffsbauer mit zoologischem Zusatzstudium als Projektleiter eingesetzt. Hat Gott sich geirrt, als er den unterqualifizierten Noah zum Projektleiter bestellte? Nein. Denn Flora und Fauna haben die Sintflut überlebt. Noah hat seine Sache gut gemacht.

Damit ein Projekt Erfolg hat, ist es nicht immer zwingend notwendig, dass der Projektleiter über Fachwissen verfügt. Meiner Erfahrung nach kann Fachwissen sogar den Blick für das Wesentliche trüben - so geschehen bei einem großen Bankinstitut in Osteuropa. Meinen Einsatz hier begann ich als Interimsvorstand. Von einem Tag auf den anderen aber fand ich mich in einem Riesenprojekt wieder, das kurz vor dem Scheitern stand. Darauf war ich so gut vorbereitet wie Noah auf den Bau der Arche - nämlich gar nicht.

Wie alles begann

Im September 2001 stellte ein großes Bankinstitut - Bilanzsumme im mittleren zweistelligen Milliardenbereich - fest, dass bei einer seiner Osteuropa-Töchter ein Millionenbetrag fehlte. Ich war bei dem Finanzinstitut in meiner Stabsfunktion als Krisenmanager und Troubleshooter tätig. Als sich zeigte, dass die Tochter mit der Krise alleine nicht fertig wurde, musste ich im Dezember 2001 ausrücken. Schnell war klar, wohin das Geld verschwunden war und wer dafür die Verantwortung trug. Man zog die Konsequenzen. Zwei Vorstände mussten gehen, ihre Aufgaben sollte ich als Interimsvorstand übernehmen. Ich war mir nicht sicher, ob ich dieser Riesenaufgabe gewachsen war. Die Kollegen und Kolleginnen in der Zentrale klopften mir auf die Schulter: "Du machst das schon, wir sind immer für dich da und jetzt mach’s gut."

Im Projektmanagement und insbesondere in der hektischen Finanzbranche ist es durchaus üblich, dass der Auftraggeber den Projektleiter mit seiner Aufgabe alleine lässt. Der Projektleiter ist in dieser Situation einer immensen Belastung ausgesetzt, die kaum jemand über einen längeren Zeitraum aushalten kann. Vorstände, die Aufträge vergeben und sich dann zurückziehen, handeln nicht böswillig. Vielmehr empfinden sie andere Aufgaben als dringlicher. Der Troubleshooter wird gut bezahlt und sollte deshalb ihrer Ansicht nach seine Aufgabe allein erledigen können. Sie übersehen dabei, dass die Unterstützung und Rückendeckung des Auftraggebers für den Projekterfolg wesentlich ist.

Auch ich konnte auf keine Unterstützung des Auftraggebers hoffen. Da hatte ich also mein Projekt. Aber das sollte nicht alles sein: Es gab noch ein zweites Projekt, allerdings wusste ich das zu diesem Zeitpunkt noch nicht.

Der Babuschka-Effekt: Projekt im Projekt

Während ich in den folgenden Wochen rund um die Uhr damit beschäftigt war, die Bank wieder auf Gewinnkurs zu bringen, kam eines frostigen Januartages meine Assistentin mit der Nachricht, dass jemand von der Nationalbank mich sprechen wolle. Weder sie noch ich hatten eine Ahnung, worum es ging. Das erfuhren wir aber schnell. Die Nationalbank hatte mitbekommen, dass ein neuer Vorstand im Amt war. Sie hatte mir zwei Monate Zeit gegeben, um mich einzuarbeiten, vermutete aber, dass mir niemand von diesem einen Projekt erzählt hatte, das unsere Bank erledigen musste. Nun wollte die Nationalbank sichergehen, dass ich Bescheid wusste. Ihr Gesandter hielt mir ein offizielles Schreiben aus dem Jahr 1999 unter die Nase und sagte: "Sie wissen aber schon, dass Sie nur noch bis zum 31. März Zeit haben?“ Ich wusste gar nichts. Ich sah den Schrieb zum ersten Mal. Darin stand, dass unsere Bank ihre drei IT-Systeme bis zum 31. März integrieren musste. Das war in zweieinhalb Monaten! Ich bat um Fristverlängerung. "Abgelehnt", antwortete der Gesandte. "Wussten Sie das nicht? Wir haben die Frist schon einmal verlängert. Eine weitere Verlängerung verbietet das Nationalbankgesetz. Entweder erfüllen Sie die Auflage oder wir entziehen Ihnen die Lizenz.“ Da war mein zweites Projekt: Die Bank retten.

Das Spezialisten-Syndrom

Als ich die Kopie des Dokuments meinen Mitarbeitern zeigte, war keiner zuständig - außer die beiden gefeuerten Vorstände natürlich. Ich bat in der Zentrale um Unterstützung. Die Zentrale teilte mir mit, dass sie in der Vergangenheit schon mehrfach versucht hatte, dieses Problem zu lösen. Ihre Bemühungen waren aber jedes Mal an den Bedenken und Besonderheiten der bankinternen Führungskräfte gescheitert. Unser Zentralvorstand sagte ganz klar: "Das Problem wird jetzt entweder lokal gelöst - oder gar nicht mehr."

Nach diesem Gespräch fühlte ich mich richtig schlecht. Was macht man in so einer Situation? Man setzt einen erfahrenen IT-Experten als Projektleiter ein und betet, dass er ein Wunder bewirkt und das Unmögliche irgendwie doch möglich macht. Das Problem dabei war nur: Wir hatten bereits so einen IT-Experten. Nämlich jenen, der in den letzten drei Jahren das Projekt geleitet und vergeblich versucht hatte, die IT-Integration zu bewerkstelligen. Ich hätte ihn freilich auswechseln können, doch das war mir zu riskant. Wenn ich einen neuen IT-Experten als Projektleiter einsetzen würde und dieser die Integration auch nicht rechtzeitig schaffte, dann war die Bank tot. In dieser Situation beschloss ich, mich über die weit verbreiteten Gepflogenheiten in IT-Projekten hinweg zu setzen. Ich ernannte den alten Projektleiter zum technischen Leiter des Projekts. Neuer Projektleiter wurde der Mann, der am wenigsten dafür geeignet war (zumindest wenn man die üblichen Kriterien für die Auswahl von Projektleitern anlegte). Es war der Mann, der keinerlei IT-Fachkompetenz mitbrachte und von IT ungefähr so viel Ahnung…

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
13 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 84
Kommentare 13

Alle Kommentare (13)

Florian
Pariente

Ein wirklich kurzweiliger Artikel, der das Lesen von PM-Praktiken zum Genuss macht. Ein Projektergebnis nach dem Pareto-Prinzip ist allemal besser als kein zufriedenstellendes Ergebnis. Es zeigt sich immer wieder, daß gutes Projektmanagement auch aus einem großen Anteil weicher Faktoren besteht.

 

Hermann
Schmidbaur

Amüsanter Artikel. Im Prinzip geht es darum, den Scope geeignet anzupassen. Dazu muss man aus der Tiefe der Probleme nach oben steigen - eben um die wirklich notwendigen Lieferanteile zu erkennen. Und - diese mit den "Auftraggebern" zu verhandeln. Tatsächlich gibt es in den Lieferanteilen eines Projektes oft genug Anforderungen, deren Notwendigkeit eher Vermutungen als tatsächlichen Notwendigkeiten entspricht. Und - ich habe auch schon erlebt, dass essentiell notwendige Anforderungen nicht einmal in den Requirements aufgeführt wurden. Um den Bogen zu schließen: ein Projektleiter muss genügend Sachkenntnis besitzen, um urteilen zu können. Das ist der Punkt, an dem Sachkenntnis unverzichtbar ist. Ein Glück dass Noah nicht navigieren musste!

 

Guest

Sehr guter Artikel.

 

Guest

Guter uns ausführlicher Artikel!

 

Guest

Fachkompetenz ist wichtig. Leider nicht immer gegeben!

 

Guest

Ein sehr nützlicher Artikel.

 

Guest

Wenn ein Projektleiter das kann, dann ist er gut

 

Thorsten
Wilkens

Toll geschrieben und auf den Punkt gebracht. Natürlich sind viele Allgemeinplätze und Standardvorgehen beschrieben, aber in der Kombination mit der Projektproblematik gut dargestellt. Lesenswert!

 

Roberto
Frezza

Sehr interessante Beschreibung der Problematiken und erfrischend pragmatisches Vorgehen. Lesenswert!

 

Harriet
Schack

Was hier so locker, flockig beschrieben wird ist schon eine echte PM Meisterleistung. Es gehört eine gute Portion Selbstvertrauen und Mut dazu das operative Geschäft der "Basis" zu überlassen und sich auf die Vision und die Motivation zu konzentrieren. Natürlich managet eine gut ausgebildete und erfahrene "Basis" ein Projekt sehr selbständig - wenn das Ziel allen Teammitgliedern klar ist. Leider werden Projekte zu oft in ihrer Effektivität und Effizienz durch sinnlose Micromanagement Entscheidungen von schlechten Projektleitern behindert. Ich bin immer wieder erstaunt welche Leistungsfähigkeite eine von der Leine gelassene Basis zeigen kann.

 

Guest

Hervorragender Artikel, mit viel Humor und Fachverstand (!) geschrieben. Danke.