Über Projekt Management (German version)

Click here for English version

Die Projektanfragen, die mich in der letzten Zeit erreichen unterscheiden sich von denen früherer Jahre – Projektanbieter fordern zwar noch Erfahrungen in einer oder optional mehreren der allseits bekannten Projektsteuerungsmethoden (Prince2, PMI etc.) vorausgesetzt, allerdings wird, so meine ich bemerkt zu haben, weniger Wert auf eine bestimmte Methodik oder Zertifizierung gelegt („nice to have“) .

Hinsichtlich dieser Projektmanagementmethoden stellt eine ehrlich erworbene Zertifizierung- ein Indiz dar , dass der/die Zertifizierte sich (1) weitestgehend mit der Thematik bezüglich der anzuwendenden Projektmanagement-Methodik beschäftigt hat und (2) Die Terminologie beherrscht, d.h. sich im entsprechenden Umfeld bewegen kann.
Die nicht immer unerheblichen Kosten derartiger Zertifizierungen werden zumeist von Arbeitgebern getragen, was ein weiterer Grund sein könnte, dass eine solche bei Freelancern nicht unbedingt in jedem Fall obligatorisch gefordert wird., zumal hier auch folge- und laufende Kosten für Re-zertifizierungen ggf. das Belegen von weiterqualifizierenden Trainings (z.B. PMI) anfällt. Erfahrene und breiter aufgestellter Freelancer werden sich ohne Not kaum auf eine Methodik festlegen wollen, und für diese dann auch noch unnötig Geld ausgeben.

Die über die reine PM-Methodik hinausgehenden Fertigkeiten und Skills, die ein erfolgreiches Projektmanagement dem Projektmanager abverlanget werden in den einschlägigen Zertifizierungen (PMI, Prince2, RUP) demzufolge nur am Rande und indirekt behandelt.

Über die „wahren“ Projektmanagement-Skills.

Welches sind nun die, zugegebenermaßen schwierig zu messenden und somit schwierig zu zertifizierenden – Eigenschaften und Skills, die ein Projektmanager, ob freiberuflich oder angestellt unterwegs, in seinem Portfolio haben soll?
Ich nehme im Folgenden nicht den Anspruch der Vollständigkeit für mich in Anspruch sondern beziehe mich auf meine Erfahrungen der letzten Jahre in den Bereichen Software-Entwicklung, DevOps und Infrastruktur.

Die initiale Analyse

Zu Anfang, d.h. bei Eintritt in ein neues Projekt, geht es darum, die richtigen Fragen zu stellen, um die aktuelle Situation und die darauf basierende Planung zu analysieren und ggf. zu korrigieren. Dies gilt sowohl für neu aufgesetzte Projekte als auch für bereits laufende Projekte. Es kann sehr gut passieren dass ein zunächst als „grün“ erscheinendes Projekt (dass zumindest im Interview als ein solches verkauft wurde) sich als rot erweist. Eine solche Analyse muss vom neu eingetretenen Projektleiter mit der notwendigen Vehemenz aber auch mit dem notwendigen Fingerspitzengefühl durchgeführt werden.

  • Der Eintritt in ein Projekt ist der beste Zeitpunkt, sofort alle notwendigen Fragen zu stellen. Wenn dies versäumt wird bzw. Der neue Projektmanager mitläuft, werden die Widerstände gegen Veränderungen zu einem späteren Zeitpunkt noch wesentlich höher sein.
  • Anders ausgedrückt: Es ist für einen neuen Projektmanager leichter, die notwendigen Änderungen gleich zu Beginn durchzusetzen, wenn die Hoffnungen noch auf ihm/ihr liegen. Später trifft das nicht mehr zu – dann ist der Projektmanager / die Projektmanagerin bereits Teil des Problems.

Im günstigsten Fall fällt dies mit der Einarbeitung des PM zusammen, wenn das Projekt sich tatsächlich in dem vorgegeben Zustand befinden.

Bei den ersten Anzeichen, dass irgendein Projektergebnis, z.B. ein Teilsystem, sich nicht in seinem offiziell festgestellten Zustand befindet, muss der tatsächliche Status ermittelt werden – dann am besten für alle Komponenten.
Wenn sich derartige Abweichungen der realen von den offiziell ermittelten Status häufen, ist der PM auf Mithilfe weiterer Projektmitarbeiter bei der Analyse angewiesen. Dies wird den Projektfortschritt wiederum verlangsamen.

Gerade in ambitionierten Projekten, in denen in rascher Folge Releases mit Kundennutzen erzeugt werden, passiert es, dass es trotz agiler Vorgehensweise zu einer Situation kommt, in der sich „plötzlich“ die Systemkomponenten nicht mehr integrieren lassen.

Der Grund hierfür besteht in der kontinuierlichen Anhäufung technischer Schulden über die letzten Iterationen.
Gerade in Projekten, die sich zum Ziel setzen, Releases in hoher Frequenz auszurollen und in Produktion zu bringen sollte das Auftürmen technischer Schulden durch agile Vorgehensweisen und Techniken wie Continuous Integration und Continuous Delivery in Grenzen gehalten werden.

Technische Schulden werden, so die mittlerweile langläufige Praxis, bewusst in Kauf genommen, z.B. weil ein notwendiges noch zu erstellendes Subsystem erst für eine weitere Projektphase geplant ist. Hier müssten dann sog. Mocks oder Scaffolds eingesetzt werden, ohne dass es bereits eine Schnittstellen-Spezifikation gibt. Die Sinnhaftigkeit einer derartigen Planung werde hier nicht weiter diskutieren.

Es gibt neben den technischen Schulden noch eine andere Form von Altlasten, die ich „Hidden Backlog Items“ (HBIs) nennen möchte.
HBIs sind Unsauberkeiten und Unvollständigkeiten, die Entwickler bewusst in Kauf nehmen.
Das Motiv für HBIs ist, dass das System oder die Applikation „im Moment“ auch mit der derzeitigen unvollständigen Implementierung einsetzbar ist, solange bestimmte noch zu implementierende Use Cases noch nicht verfügbar sind. Der Programmierer nimmt sich zumeist vor, einen solchen Mangel zu beheben – „demnächst“ bzw. „wenn die Zeit dafür da ist“.
Die Gefahr von HBIs liegt auf der Hand:

  • Die Abarbeitung derartige HBIs wird entweder vergessen oder
  • Sie blähen die an sich geringen Aufwände für die Implementierung zukünftiger Features künstlich auf.

In jedem Fall haben HBIs zwei Konsequenzen:

  • Eine Projektplanung wird unmöglich gemacht
  • Es kommt zu unerwarteten Fehlen bei den Integrationstests.

Die Tatsache, dass mit Sachverstand durchgeführte Code Reviews und wohldefinierte und eingehaltene Definitions of Done derartige HBIs frühzeitig identifizieren bzw. verhindern könnte, wenn es denn mit fachlichem Sachverstand kombiniert würde, sei dahingestellt.

Es ist die Aufgabe des Projektmanagers, diese HBIs zu identifizieren und sie, wenn möglich, den technischen Schulden zuzuordnen und einzuplanen.

Bei den HBIs, die nicht in die Kategorie der technischen Schulden eingeordnet werden können, z.B. Known Errors oder Problems, müssen diese natürlich ebenso eingeplant werden, mit der entsprechenden Priorität.
Konsequent betrachtet, dürften im Rahmen einer wirklich agilen Software-Entwicklung gar keine technischen Schulden im größeren Rahmen – und HBIs schon gar nicht.
Über technische Schulden

Und in der Tat stellt sich natürlich die Frage, woher in einer der kommenden Iteration auf einmal die Zeit kommen soll, die man jetzt nicht hat, um eine technische Schuld wieder abzutragen.

Die geforderten Projektmanagement-Skills

Persönlichkeit

Es ist sicherlich in den wenigsten Fällen ein Option, das gesamte Projekt auf on Hold zu setzen. Stattdessen, müssen die identifizierten technischen Schulden und HBIs in den Projektplan eingeplant werden, was dann natürlich Konsequenzen in Bezug auf die Einhaltung der Deadlines bzw. der Zusagen an den Kunden bzw. „das Business“ hat.
Deshalb ist vom Projektmanager Durchsetzungsvermögen in Kombination mit dem notwendigen „Fingerspitzenprofil“ gefordert. Es bringt einem PM nichts, umgehend nach Projektantritt alle beteiligten vor den Kopf zu stoßen und Ihnen zu zeigen, was nicht funktionieren kann und wird.
Insbesondere im interkulturellen Umfeld ist diese Fähigkeit von Belang. Nach Erfahrung des Autors spielt sich der Großteil der ernstzunehmenden Projekte derzeit im internationalen –wenn nicht im globalen- Umfeld ab. Bei interkulturellen Konstellationen wird vom PM oftmals ein seniores und durchsetzungsstarkes Verhalten erwartet – in Verbindung mit den in manchen Kulturen übliche Art und Weise, Probleme zunächst indirekt zu adressieren.

Übergabefähigkeit

Der Begriff „Übergabe“ bezieht sich nicht nur auf die einmalige Übergabe des derzeitigen Projektes an eine Urlaubsvertretung oder einen Nachfolger, sondern auch und insbesondere auf die fortwährende, d.h. periodisch wiederkehrende Übergabe des Projektes durch den Projektleiter an ….. sich selbst. Dies setzt die Fähigkeit zur Dissoziation voraus.

Technisches Verständnis

Obwohl von einigen Vertretern des Projektmanagement verneint, ist ein technisches Verständnis sehr hilfreich, um die richtigen Fragen mit der notwendigen Vehemenz an Entwickler stellen zu können.
Es geht hier nicht darum – und es darf dem PM nicht darum gehen, Architekten oder Programmierern in den Arm zu fallen oder mit wohlfeilen Ratschlägen zu kommen, sondern eine möglichst realistische Einschätzung der Lage zu erlangen.

Die zwei Pole des Projektmanagements

Die reguläre Arbeit des PM erfordert zwei Eigenschaften, die konträr zueinander stehen:
Prozessorientierung und Zielorientierung

Zur Prozessorientierung

Das sagt sich so einfach: Der/die PM muss jeden Schritt des durch die im jeweiligen Projekt fgeforderte Methodik immer wieder durchführen- eine Sysiphus-Aufgabe par Excellence, die Unabhängig von der jeweiligen Projektsituationsdurchgeführt werden muss, z.B. Status-Feststellungen, Reviews, Projektplan- und Dokumentenpflege im geforderten Detailgrad erfordern einen hohen Grad der Selbstorganisation und dergleichen Routineaufgaben.
Die Prozessorientierten Aufgaben erfordern vom PM auf jeden Fall die Bereitschaft zur Sisyphusarbeit. Routinemäßige Abläufe müssen konstant wiederholt und qualitativ einwandfrei durchgeführt werden.
⇒Im Sinne der Prozessorientierung ist die Gewissenhaftigkeit einer „fleißigen Ameise“ gefragt

Zur Zielorientierung

Der PM muss die offiziellen Ziele stets im Auge haben und behalten. Aufgaben entsprechend zu priorisieren, zu re-priorisieren und die Projektmitglieder von Aufgaben und Einflüssen, die diesen Aufgaben entgegenstehen, abzuschirmen.
Er/sie darf nicht davor zurückschrecken, Aufgaben zu (re-)priorisieren und Arbeitsergebnisse zu verwerfen , wenn dies zur –schnelleren- Erreichung von Zielen notwendig ist.

Im Sinne der Zielorientierung ist eine Gewisse Innovations- und Entscheidungsfreude gefragt, wie sie ein Entrepreneur aufbringen muss.

Conclusio

Kein PM wird als PM geboren – dies mag ein Allgemeinplatz sein, der für viele Berufsbilder gelten mag – m.E. für die Rolle des PM im Besonderen: Dieser muss, im Spannungsfeld zwischen Prozess- und Zielorientierung effizient und effektiv agieren können.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.