Tag Archives: Executive

Oft werde ich gefragt, woran man erkennen kann, ob ein Kandidat für eine Projektleiterstelle sein „Handwerk“ kann oder nicht. Das kann man natürlich erst wirklich wissen, wenn man mit ihm/ihr zusammenarbeitet. Aber im Laufe meiner vielen Jahre im Projektmanagement glaube ich, ein paar „Patterns“ zu wissen, die zumindest Hinweise auf die Qualität geben können.

Selbstorganisation und Strukturiertheit

So kann man sicherlich ein Projekt nur dann strukturiert und zielgerichtet leiten, wenn man selbst eine gute Selbstorganisation und Strukturiertheit besitzt. Ein gutes Ablagesystem zum Finden von Information allgemein und sinnvolle Projektablagen im Speziellen sowie ein guter Überblick sind für mich Grundvoraussetzungen, bei einem Projekt „on top“ zu sein und zu bleiben, auch wenn’s mal etwas brenzlig wird.

Oftmals genügt schon ein schneller Blick auf den Desktop eines Bewerbers. Ist der überfüllt, mit vielen ungeordneten Icons/Verknüpfungen, oder organisiert, geordnet nach den wichtigsten Arbeitsthemen? Gleiches gilt für die Outlook Inbox. Ist die aufgeräumt, abgearbeitet und/oder sortiert in eine strukturierte Ablage, oder überfüllt mit vielen ungelesenen Nachrichten? Daran kann man schon ganz gut erkennen, wie jemand arbeitet…

Methodik und Praxis

Oft sieht man aber schon im Bewerbungsschreiben einige Hinweise auf das Bewerberlevel. Um es gleich vorweg zu nehmen: Ich kenne eine Menge guter Projektmanager ohne Zertifikat und auch viele mit einem solchen, die aber von Projektmanagement keine Ahnung haben. Immerhin geben erworbene Zertifizierungen einen Hinweis auf eine mehr oder weniger fundierte Ausbildung. Die dabei vermittelten Best Practices geben überdie die Möglichkeit zur Selbstreflexion des eigenen (Projekt-)Handelns. Autodidakten hatten hingegen nur dann eine Chance zum gedeihlichen Lernen, wenn sie auch gute Vorbilder hatten…

Im Bewerbergespräch erfährt der im Projektmanagement geübte Interviewer auch, ob der Kandidat seine Methodik(en) verstanden hat und situativ, d.h. mit einer gewissen Auswahl und ohne Dogmen anwendet. Evangelisten ersetzen nur die Irrtümer des einen mit denen eines anderen Ansatzes.

Und natürlich sollte der Lebenslauf bzw. die Projekthistorie des Kandidaten auch Aufschluss über die erfolgreiche Ablieferung, also im Zeitplan, im Budget und in der erwarteten Qualität, vergangener Projekte geben. Andernfalls muss man das gezielt hinterfragen.

People Skills

Die sogenannten “weichen” Faktoren werden in ihrer Erfolgskritikalität gern unterschätzt. Das gilt insbesondere dann, wenn man Fachspezialisten zu Projektleitern „hochlobt“. Tatsächlich ist jedoch einer der Hauptaufgaben des Projektmanagements, Mitarbeiter zu motivieren und Zusammenarbeit zu fördern. Da die Teammitarbeiter in der Regel ihre Aufgaben möglichst ungestört erledigen möchten, gehört dazu z.B. auf wenige und gut strukturierte Meetings zu achten. Zeigt der Bewerber einen Hang zum Micro-Management (wie es oft bei Projektleitern aus der technischen Fachmannschaft auftritt), so wird er seinen Job als Projektmanager schnell vernachlässigen. In Krisensituationen wird er sich wahrscheinlich auf sein Fachgebiet zurückziehen. Projektmanagement fällt dann hinten runter. Gute Teamplayer setzen dagegen auf Eigenverantwortung, Rollen und Delegation und halten die Ergebnisse strukturiert nach.

Nicht jeder Kandidat besitzt zudem die zweite wichtige „weiche Zutat“, nämlich Führungsqualität. Diese muss ein guter Projektmanager sowohl gegenüber Mitarbeitern als auch in Richtung seiner Entscheider/Vorgesetzten haben. Der Fokus sollte dabei auf guten Entscheidungen, die das Projekt vorwärts bringen, liegen. Überhaupt zeigen gute Projektmanager ganz allgemein ein ausgeprägtes Stakeholder und Change Management, und sie reden Tacheles !

Im Bewerbergespräch achte ich zudem auf Augenkontakt, Verbindlichkeit und Konsequenz, die Indikatoren für gute Führung sind. Um aus Mitarbeitern ein erfolgreiches Team zu machen, braucht es auch im Projektmanagement ganz viel Authentizität, das, was man einfordert, auch selbst vorzuleben…

Im Vorstellungsgespräch

Leider treffe ich in Vorstellungsgesprächen sehr oft auf Bewerber, die sich vielleicht über die Webseite etwas auf das Unternehmen vorbereitet haben, zum ausgeschriebenen Job jedoch nur wenig bzw. sehr allgemein gebrieft sind. Das mag auch in vielen Fällen mit dem vorgeschalteten Auswahlprozess, z.B. über Recruiter oder den Einkauf zusammenhängen. Damit erhält man leider oft die Billigsten statt die Besten…

Ein Kandidat für eine Projektleiter-Position muss kein ausgesprochener Fachmann sein (s.o.), wichtig sind aber eine Affinität und ein Interesse an der Aufgabe, am „Betreff“ des Projekts.

Opportunistische Bewerber oder solche, die sich mal „anders als bisher“ beweisen wollen, lehne ich grundsätzlich ab. Hingegen honoriere ich die altbekannten Tugenden für Potenzial: Motivation, Neugier, Scharfblick, Engagement und Entschlossenheit.

Ein interessierter Kandidat versucht sein Verständnis zum Projekt und den Erwartungen des Auftraggebers zu vertiefen. Mich interessiert da vor allem genauer Projektinhalt und –umfang, auch z.B. ob es sich um Green Field oder Brown Field Projekt, eine Erstinstallation oder eine Migration von Legacy handelt usw.

Das Projekt Setting, etwa Unternehmen, Branche, Status, Lieferanten, Stakeholder, Teamgröße und ‑Zusammensetzung, ob man dedizierte Mitarbeiter im Projekt hat und ob diese an einem Ort oder virtuell verbunden arbeiten usw. ist für das Einordnen und die Beurteilung der zu übernehmenden Aufgabe essenziell.

Weitere Fragen des Kandidaten sollten die Report- bzw. Eskalationswege im Projekt und seine eigenen Kompetenzen klären. Etwa ob eine Doppelspitze mit einem technischen Projektleiter oder mit dem eines Lieferanten vorgesehen ist. Und schließlich sollte Klarheit über die Modalitäten des eigenen Ramp-ups bis zur Übernahme der Projektverantwortung erzielt werden.

Selbstredend sollten der Interviewer bzw. die Gesprächspartner im Interview auf all diese Fragen auch selbst ausreichend vorbereitet sein. Und vielleicht sollte man auch bereit sein, nach der genauen Auftragsklärung auch noch einmal über den Preis zu reden. Die von vielen Vermittlern verlangte Honorarangabe ohne vorherige, genügende Aufgabenprüfung halte ich für unseriös…

Profiling zur Vorbereitung

Den richtigen Projektmanager für ein Projekt zu finden ist offensichtlich kein Zufall sondern braucht gute Vorbereitung. In den Sanierungsprojekten, die ich wieder auf den „Pfad der Tugend“ zurückführe, übernehme ich selbst oft die Suche nach einem geeigneten internen Nachfolger und wende die oben genannten Kriterien an. Aber auch für Projekte, die erst noch aufgesetzt werden sollen, ist die Checkliste sicher hilfreich. Außerdem kann man sich dabei auch professionell unterstützen lassen. Schauen Sie einfach mal bei https://pm-professionals.eu/?page_id=109 nach, wie.

Es hat sich schon viel gebessert. Noch bis vor nicht allzu langer Zeit standen die Agilen Jünger dem klassischen Projektmanagement und seinen Projektmanagern unversöhnlich gegenüber: Agil als einzige, neue Wahrheit in der Durchführung von Projekten war hip und der durchgeplante Wasserfall sowas von gestern. Folglich proklamierten auch eine große Anzahl von Unternehmen den Hype „Wir sind jetzt agil“ – und fielen mehrheitlich böse auf die Nase. Dies möchte ich heute einmal etwas analysieren und für einen Mittelweg werben.

Agil ist man nicht auf Ansage, es ist eine Geisteshaltung, ein Mindset, der sich so sehr vom bisher gewohnten Unternehmens-Paradigma der Hierarchien, Planung und Kontrolle unterscheidet, dass sie zunächst einmal für solche „gewachsenen“ Unternehmen zumindest schwer verdaulich ist. Bedenkt man all die liebgewordenen Fürstentümer und Vorschriften-Komfortzonen: Es braucht eine lange, behutsame Transformation, angefangen beim Top- und Mittelmanagement bis in die Projekte hinein, um den Kulturwandel zu partizipativem, kollektivem und selbstorganisiertem Handeln zu vollziehen.

Fallbeispiel Sanierung eines “klassischen” Projekts

In meinem heutigen Beispiel tauchen wir ein in ein typisches deutsches Unternehmen, das seine Kernprozesse von der Akquise über die Auftragsbearbeitung und ‑ausführung bis zur Fakturierung und dem Mahnwesen beschreiben, standardisieren und mit IT-Unterstützung digitalisieren wollte. Dabei hatte man – wie immer – der starken internen IT-Abteilung den Auftrag zur Umsetzung erteilt und sich hernach in den Fachabteilungen wieder auf das Tagesgeschäft konzentriert. Nach einem halben Jahr traditionellem Projektmanagement in der IT wurde der Pilot stolz in der ersten Niederlassung vorgestellt. Business wie IT waren enttäuscht von der Reaktion der jeweils anderen Seite. Über ein Jahr der schmerzvollen Nachbesserungen folgte, bis das Produkt halbwegs gebrauchsfähig war, Kosten und erhoffter Time-to-Market liefen davon. Die Geschäftsleitung zog die Notbremse.

Aktive Beteiligung des Business

Mein erster Vorschlag zur Sanierung war, die Fachseite aktiv am Projekt zu beteiligen, sie in den Driver Seat zu setzen. Das ist in vielen „IT-Projekten“ ungewöhnlich (!?!), denn erstens hat das Business für „sowas“ ja keine Zeit und zweitens meist keinerlei Erfahrung, wie man das macht. So auch in diesem Fall: Fehlanzeige bei Anforderungs- und Projektmanagement. Also: Grundlagen einführen und dedizierte Projektmitglieder aus den Fachbereichen einfordern. Die IT-Leitung lehnte sich zurück und erwartete unsere Bauchlandung. Dennoch hatten wir in relativ kurzer Zeit eine kleine, sehr engagierte Truppe zusammen, die sich erstmals eingehende Gedanken über die Prozesse machte, die da von der IT abgebildet werden sollten.

Gleichzeitig schaute ich mich im Unternehmen etwas um und fand ein paar weitere Projekte anderer Fachseiten, die sich just mit den gleichen Themen beschäftigten und bei der IT dafür Ressourcen angefordert hatten. Die Geschäftsleitung erkannte die Sparpotenziale und Synergien sofort. In den „Fürstentümern“ regte sich zunächst Widerstand gegen die nun folgenden Konsolidierungen. Ich gab meinen Team-Mitgliedern eine kleine Einführung ins Veränderungsmanagement und holte Leute aus den anderen Abteilungen mit in unser Boot.

Was hat das bisher mit Agil zu tun? Nun, eine Grundvoraussetzung für alle agilen Vorgehensweisen ist eine intensive, aktive Beteiligung der Fachseite, die ja die Product Owner stellen muss. Und die müssen wissen, wie das Ergebnis aussehen soll, also was die Definition of Done in Reviews und Tests sein soll. „Klassisches“ Anforderungsmanagement wie bei unserer Prozessdefinition mag zwar nicht genau ins agile Bild passen, aber wir haben immerhin bereits hier mit allen Beteiligten sehr iterativ gearbeitet, und in vielen Teilen haben wir auch Elemente aus dem Design Thinking genutzt.

Das zeigt aber auch, dass in Unternehmen, die noch nicht gesamtheitlich agil „ticken“, ein hybrider Ansatz zielführender sein kann als einer „by the books“. Das kompetent und der Situation angemessen beurteilen zu können und zu entscheiden ist letztlich die Aufgabe und der Skill eines guten Projektmanagers, den es ja so in der agilen Welt auch nicht gibt.

Anforderungen: „klassische“ Ermittlung der Features und User Stories

Mithilfe einer kleinen Unternehmensberatung, die uns bei der Anforderungs- und Prozessbeschreibung unterstützte, kamen wir in allen Bereichen gut voran. Und siehe da: Viele der Abteilungs-Prozesse überschnitten sich oder waren sogar weitgehend gleich ! Aus diesen ca. 80% ließ sich mit etwas Abstraktion und Konzentration auf das Wesentliche am Ende ein einziger, gemeinsamer End-to-End-Ablauf mit nur ganz wenigen aufgabenindividuellen Schleifen machen. Eine signifikante Einsparung für den kommenden Entwicklungsaufwand und ein riesiges Synergievolumen für das Unternehmen aus der Prozessoptimierung und –standardisierung !

Grobschätzung statt definitiver Budgets spart Zeit

Ein zweiter, häufiger Hinderungsgrund, Projekte tatsächlich agil durchzuführen, liegt in der Beharrlichkeit der Auftraggeber auf Managementebene auf „klassischem“ Reporting aus dem Projektmanagement: Wann liefern wir was zu welchen Kosten, wie ist der aktuelle Status gemessen an der Abarbeitung der Planung usw.? In unserem Fall wurde das noch verschärft durch meinen zweiten Vorschlag: Wir wollen von der IT keine definitive Kostenschätzung, sondern auf Basis der Prozessbeschreibungen und der damit involvierten Systemkomponenten eine in der Genauigkeit „Rough Order of Magnitude“. Achtung, jetzt wird’s wieder agil: Damit wollten wir uns eine langwierige, detaillierte Anforderungsdokumentation sparen und schnell an die Umsetzung kommen, die Prioritäten der Backlogs abgestimmt in den Fachteams und auf der technischen Seite mit der IT.

Der Aufschrei war zunächst groß. Die Geschäftsleitung wurde unruhig angesichts großer Zahlen in einem Kostenkorridor von +/- 50%, lies sich aber auf einen mittels Drei-Punkte-Schätzung angenommen Kostenumfang mit Obergrenzen schließlich ein. Viel größer war das Ringen mit der IT-Leitung, sich auf eine solche Kostenschätzung einzulassen, ganz ohne Lasten- und Pflichtenhefte und genaue Kalkulation (die dann wohl doch nicht eingetroffen wäre).

Wir haben viel Zeit verloren, bis wir endlich auf nachdrückliche Anweisung des Vorstands unseren ROoM-Kostenvoranschlag zur Genehmigung des Budgets erhielten. Vielleicht hat etwas geholfen, dass wir im Kompromiss die Konfiguration des ERP-Systems als Basiskomponente der Gesamt-Topologie auf „klassische“ Projektmanagement-Weise akzeptiert haben. Am Ende ist dieses Teilprojekt aber eben doch nicht mit der geplanten Zeit ausgekommen und hat sogar den oberen Korridor, den wir trotz „genauem“ Kostenvoranschlag zuließen, noch knapp gerissen…

Gemeinsame Entwicklung: gemeinsame Probleme und Akzeptanz

Die übrigen Nicht-ERP-Komponenten sind wir iterativ-inkrementell angegangen. Aber auch hier hat es Wochen der Überzeugungsarbeit gebraucht, um die IT davon abzubringen, zuerst genaue Anforderungsdokumentationen erstellen zu wollen. Wir hatten Features und User-Stories, die sich an den Prozessschritten entlang hangelten. Wie die genau aussehen sollten, das wollten wir, Fachseite mit der IT, gemeinsam erarbeiten und eine nach der anderen iterativ und lauffähig umsetzen. Für die Fachseite war das sowieso alles neu, aber man konnte sich jetzt richtig einbringen und „sein Baby“ bauen – die Akzeptanz war hoch, auch auf Auftraggeberseite im Management.

Auch die Entwickler in der IT fanden den Ansatz gut, hatten sie doch bei Fragen und Abstimmungen immer einen direkten Ansprechpartner auf der Businessseite. Und die Dokumentation sollte erst erstellt werden, wenn man fertig war und feststand, wie es schlussendlich gemacht worden war. Nur die IT-Leitung tat sich zunächst mit der Aufgabe der Projektmanagement-Kontrolle insbesondere in der Ressourcenplanung und der Transparenz in Fortschritt und auch Problemen schwer.

An die Fachseite stellte die Vorgehensweise die schwierige Anforderung, immer genügend eingearbeitete und miteinander abgestimmte Ansprechpartner vorzuhalten, die möglichst auch aus dem prallen Leben der Praxis kamen, aber dennoch das Abstraktionsvermögen hatten, nach den definierten Prozessen und nicht nach der eigenen Gewohnheit zu urteilen.

Erfolg schafft Vertrauen und Motivation

Die Geschäftsleitung wurde schon langsam mangels sichtbarer Fortschritte ungeduldig. Aber hinter den Kulissen haben wir mit jedem Meeting von Business- und IT-Leuten Vertrauen untereinander aufgebaut, den Sand aus dem Getriebe bekommen, sind ein gemeinsames Entwicklungsteam geworden und haben durch offene und ehrliche Kommunikation schließlich auch die IT-Leitung in unser Boot bekommen.

Und es begann, Spaß zu machen, gemeinsam etwas zu erschaffen, Probleme zu überwinden, Erfolge zu sehen und auch schließlich dem Lenkungskreis zeigen zu können. Die übergreifende Koordination der verschiedenen Entwicklungs-Streams habe ich „klassisch“ geplant, mit der Earned Value Methode verfolgt und berichtet, ebenso die inkrementellen Rollouts an das Business und in die Niederlassungen. Das war das „Nervenfutter“ für die Geschäftsleitung…

Fazit: Agil ist Veränderung und braucht Zeit

Der hybride Projektansatz hat in den agilen Teilen etwas länger gebraucht, bis er „zum Fliegen“ kam. Das ist zum größten Teil den Widerständen gegen gefühlten Kontrollverlust ohne eine „ordentliche“ Planung und der Angst vor zu viel Transparenz geschuldet, aber auch der anfänglichen „Unbedarftheit“ der Fachseite in der Projektarbeit und den „Notwendigkeiten“ im Projektmanagement (insbesondere Anforderungs- und Changemanagement) und –Führung.

Unsere agilen Vorgehensweisen haben sich als mindestens so effektiv wie das „klassisch“ durchgeführte ERP-Teilprojekt erwiesen, jedoch als wesentlich effizienter, wenn auch sicher noch entwicklungsfähig. Mit der Übung werden wir immer besser, der sichtbare und schnelle Erfolg wirkt als Motivator und überzeugt mehr und mehr Stakeholder im Unternehmen bis hinauf in den Vorstand. Aber es bleibt dennoch ein langer Weg, bis alle agil arbeiten und auch der Lenkungskreis das „Agile“ vollständig versteht.

Agil ist kein Allheilmittel, und aus meiner Praxis kann ich überdies bestätigen, dass Agil nicht für jedes Unternehmen und jedes Projekt vollständig oder ausschließlich geeignet ist. Es hilft aber zumindest in hybriden Projekten an den passenden Stellen eingesetzt, effizienter und flexibler zu sein, und klassisches Projektmanagement hat weiter seine Existenzberechtigung – in den Händen von Projektleitern, die ihr Handwerk verstehen. Vielleicht ist dann auch der Titel „der lange Weg zu mehr Agilität“ an dieser Stelle zutreffender.

Lesen Sie einen weiteren Artikel über hybrides Projektmanagement…