In letzter Zeit kommt es öfter vor, das ich mich verstärkt auch mit “allgemeinen” Themen der Software-Entwicklung auseinandersetze. Heute habe ich mich mit den im Alltag allgegenwärtigen Themen Projekt und Projektmanagement auseinandergesetzt. Mein Ziel und mein Interesse ist dabei auf das Management von Software-Projekten gerichtet, besser gesagt dem Projektmanager in der Software-Entwicklung gewidmet.

Aber bevor man sich dem “Management” einer Sache annimmt, sollte man definieren was diese Sache – also das Projekt – überhaupt ist. Da wären zum einen eine Reihe von formalen, klassischen Definitionen. Die gängigste ist wohl die des PMI:

“Ein Projekt ist ein zeitlich begrenztes Vorhaben, das unternommen wird, um ein einmaliges Produkt, eine Dienstleistung oder ein Ergebnis zu erzeugen.”

Project Management Body of Knowledge (PMI)

Um es also in deutlicheren Worten zu sagen: Ein Projekt ist prinzipiell alles, um ein bestimmtes Ziel in einer bestimmten Zeitspanne mit bestimmten Mitteln zu erreichen. Aus der “Entwickler-Brille” betrachtet kann also ein Projekt alles mögliche sein: Ein Bug-Fix, ein Change-Request, eine Komponente, ein Mini-Tool, eine Website, ein Framework oder eine super-duper Mega-Anwendung. Das ist für meinen Geschmack (und den vieler anderer) etwas zu schwammig, denn wenn alles ein Projekt wäre, müsste man alles auch managen – das ist offensichtlich zuviel des Guten.

Also müssen weitere Kriterien herangezogen werden, um ein “Vorhaben” und die damit verbundenen Maßnahmen als “Projekt” zu rechtfertigen. In der Software-Entwicklung gibt es eine einfache Faustregel, um Vorhaben & Aufgaben nach einer bestimmten “Komplexität” für ein Projekt auszusieben:

Die “3 mal 1 Projekt-Regel”

Alle Vorhaben oder Aufgaben, die offensichtlich

• länger als einen Tag andauern können, oder
• mehr als eine einzelne Aktion erfordern, oder
• mehr als eine Person beschäftigt

sind Projekte.

Dieser sehr groben Faustregel ist natürlich nicht strikt zu folgen, sondern eher als richtungsweisende Orientierungsregel zu verstehen und hat sich eigentlich gut bewährt. Das Fatale an dieser Regel ist natürlich, dass es potenziell viele kleine Mini-Projekte verursacht – aber das sei für’s Erste mal ausser acht gelassen. Prinzipiell gilt: Ein Projekt hat eine Zielvorgabe, eine Zeitvorgabe und natürlich die Personen & Mittel, die diese Vorgabe in der “gegebenen” Zeit umsetzen sollen.

Hat man nun ein Projekt definiert – also sich ein Ziel gesetzt, welches man bis zu einem bestimmten Datum erreicht haben will, geht es um das Management des Projektes. Auch hier gibt es wieder eine Menge an trockenen Definitionen dafür, was Projektmanagement eigentlich ist. Hier die Definition nach DIN-Norm:

“Projektmanagement ist die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes.”

DIN 69901

Eine in meinen Augen äußerst “harte” Defintion. Demnach braucht ein Projektmanager eigentlich nichts anderes zu tun, als alle Projektbeteiligten und das Projekt selbst zu “führen”. Ein Projektmanager ist also für ein Projekt eine Führungskraft. Meiner Meinung nach ist da mehr dahinter – oder besser gesagt, eigentlich etwas ganz anderes. Intuitiv stellt man sich dabei nämlich die Frage: Was muss man denn eigentlich bei einem Projekt alles “verwalten” ?

Was macht eigentlich ein Projektmanager ?

Genau hinter dieser Frage versteckt sich das eigentliche Dilemma des Projektmanagements. Abhängig von der Größe, der Dauer, der Inhalte, der Umsetzung, des Teams, der Investitionen und vielem Anderen mehr kann oder muss man besonders viele oder besonders wenige Verwaltungs- und Organisationsmaßnahmen durchführen. Das gesamte Betätigungsfeld eines Projektmanagers ist dermaßen variabel und abhängig vom Projekt, dass man es kaum greifen kann.

Trotz dieser ausgesprochen hohen Variabilität versucht man beim Projektmangament, alles mögliche zu organisieren, zu strukturieren, zu planen oder gar zu reglementieren. Das macht man natürlich nicht aus Spaß, sondern primär um die Zielvorgabe des Projektes zu realisieren – also ein Projekt erfolgreich durchzuführen. Im “klassischen” Projektmanagement gibt es da verschiedene Leitfäden, wie z.B. das Magische Dreieck, die Projektumfeldanalyse oder das sagenumwobene Teufelsquadrat.

Ich möchte noch ein klein wenig bei der bis dato sehr allgemeinen und abstrakten Betrachtungsweise des Projektmanagements bleiben, bevor ich die Dinge auf die Software-Entwicklung konkretisiere. Denn aus meiner Sicht kann man ganz allgemein unter Projektmanagement einfach die Aufgaben verstehen, allen Beteiligen

• die benötigten Informationen zu liefern,
• die notwendigen organisatorischen Maßnahmen (bzgl. Meetings, Listen, Dokumente) zu übernehmen,
• bei der Bewältigung von technischen, sozialen oder anderweitigen Problemstellungen zu helfen,
• den Überblick über das Projektgeschehen zu haben und zu vermitteln.

Betrachtet man meine obige “naive” Beschreibung des Projektmanagements näher, stellt man fest, dass die Aufgaben sich stark dem Aufgabenbereich z.B. eines Sekretärs oder einer ähnlicher Bürokraft annähern. Insofern ist die Aussage für mich zulässig, dass ein Projektmanager für ein Projekt und alle Beteiligten im positiven Sinne nichts anderes als eine Hilfskraft darstellt.

Ich möchte keineswegs den Berufsstand oder die Kompetenzen des “Projektmanagers” dadurch mindern – aber dennoch klar feststellen, das Projektmanagement in erster Instanz nichts mit Mitarbeiter- oder Teamführung zu tun hat.

Projektmanagement in der Software-Entwicklung

Vielmehr beschäftigt sich ein Projektmanager mit Kennzahlen, Analysen oder Rahmenbedingungen wie z.B. Zeit-, Ressourcen- und Budgetplanung. Das ist vor Allem in der Software-Entwicklung eine nicht zu unterschätzende Aufgabe, schließlich ist Software ein “weiches”, während der Konstruktion schwer greifbares Produkt.

Hier kommt ein in meinen Augen ganz wesentlicher Aspekt, den jeder Software-Projektmanager im Fokus haben sollte: Die Arbeit am Produkt und das Produkt so gut wie möglich “greifbar” zu machen. Greifbar nicht nur im Sinne von Metriken für Fortschritt, Dauer, Leistung, Fehlerquote oder ROI. Nein, ich meine überdies andere Dinge, wie z.B. die Visualisierung des Produktes in Form von Continuous Build / Integration, Test- oder Betaversionen, klare Anforderungs- und Informationskanäle mit geeignetem und auf das Team abgestimmten Toolset, leicht verständliche, einfache Prozesse zur Organisation der Arbeitsabläufe oder konkrete Koordinationsunterstützung mit Hilfe von Meetings, Zusammenfassungen und Dokumentationen.

Leider ist es oftmals der Fall, das Projektmanager aber auch andere Dinge tun. Ein besonderes Steckenpferd scheint dabei das Mitwirken bei technischen Entscheidungen zu sein. Manchmal geht das sogar soweit, das der Projektmanager die Richtung geradezu vorgibt. Man mag argumentieren, das in der Software-Entwicklung öfters Projektmanager schon eine “Entwickler-Vergangenheit” nachweisen können. Das alleine rechtfertigt eine technische Mitbestimmung meiner Meinung nach noch lange nicht.

Im Gegenteil, es wird dadurch für Entwickler und Manager nicht einfacher – während der Entwickler dem Manager mangelnde Detailkenntnisse entgegenwirft, entgegnet der Manager dem Entwickler seine Einschätzung zu Aufwendungen und Vorgehensweisen. Ich bin mir sicher, das viele Entwickler schon die Sätze “Der Bugfix dauert niemals so lange”, “Das kann man doch einfach runter programmieren” oder “In PHP ist das ganz easy” aus dem Munde des Projektmanagers gehört haben. Diese Aussage sollte nicht missverstanden werden – jeder Projektmanager darf und kann aus einer “Entwickler-Vergangenheit” Vorteile und Erfahrungen in seine jetzige Aufgabe einbringen – nur das “Wie?” ist entscheidend.

Abgesehen davon legen manche Projektmanager besonderen Wert darauf, die anstehenden Aufgaben den Entwicklern zuzuweisen und aktiv an der Arbeitsaufteilung mitzuwirken. Der Projektmanager hat zugegebenermaßen den “Überblick”. Aus seiner Perspektive ist er also im Idealfall wie ein Schachspieler, der das Spielfeld bzw. die Spielsituation überblickt und entscheidet, welche Spielfigur für den nächsten Zug eingesetzt wird und wie sich dadurch die Spielsituation verändert.

Die Fehleinschätzung dabei ist aus meiner Sicht schlicht und einfach die Tatsache, das man Software-Entwicklung nicht mit Schach vergleichen kann. Im Schach gibt es einen Gegner, kein Zeitdruck, keine Korrektur des Spielzugs, keine variable Leistung der Spielfiguren, keine äußeren Einflüsse und ein festes Reglement.

In der Software-Entwicklung jedoch gibt es all dies nicht. Dafür spielen andere Faktoren eine große Rolle. Das Know-How jedes einzelnen Entwicklers, die technologische Plattform, die Anforderungen und Wünsche des Kunden und vieler Abteilungen, die Altlasten, Fehler und Wartungsmechanismen, das Teamwork der Entwickler. Insofern ist es geradezu eine Überheblichkeit, das ein Projektmanager sich selbst zumutet, die Einschätzung über Aufgabenverteilung zu übernehmen oder zu steuern.

Aliges Software-Management: Rettung oder Untergang ?

Nun, mittlerweile ist in nahezu jeder professionellen Software-Entwicklung das Thema “Agile Software-Entwicklung” angekommen und wird auch schon breit praktiziert. Methoden wie Scrum oder Crystal bringen neue Denk- und Arbeitsweisen ins Management. Das interessante an den agilen Ansätzen ist die latente Ignoranz der klassischen Projektmanager-Rolle gegenüber. So ist z.B. in Scrum weit und breit kein Projektmanager in Sicht. Statt dessen gibt es Scrum Master und Product Owner. Es liegt die Schlußfolgerung nahe, das man ja eigentlich gar keinen Projektmanager benötigt.

Die Wahrheit liegt wie so oft in der Mitte. Obwohl es bei agilen Managementmethoden wie Scrum keine “echten” Projektmanager gibt, gibt es sie doch. Die “Reinkarnation” des Projektmanagers kommt dabei in vielschichtigen Formen. Der Scrum Master ist so eine Reinkarnation – er übernimmt klassische technische und soziale Teamaufgaben und hilft bei Koordination und Organisation. Der Product Owner kümmert sich um das “geschäftliche”, also Kunden, Anforderungen, Budgets und zeitliche Abläufe. Die übrigen Aufgaben des Projektmanagements werden auf das gesamte Team verteilt. Doch der Projektmanager als Person ist von der Bildfläche verschwunden.

Wenn man diese “reine Scrum-Lehre” in größeren Projekten oder Organisationen umsetzt und lebt, stellt man schnell fest, das Scrum kein einfaches Management-Modell ist. Die “Eliminierung” des Projektmanagers aus dem Vorgehensmodell bürdet den bleibenden Rollen automatisch Teilaufgaben eines Projektmanagers auf. Nach einigen Monaten spürt jeder in einem Scrum-Team, das das managen von Projekten keine leichte, erquickende Aufgabe ist. Obgleich es eine gute Idee ist, die Verantwortung des Projektes auf mehrere Schultern zu verteilen und das Team durch das gemeinschaftliche Verantwortungsbewusstsein zu stärken, ist deren Umsetzung ungleich schwerer.

Master oder Owner, das ist hier die Frage

An dieser Stelle möchte ich nicht zu tief in die Unwegsamkeiten und Potenziale von Scrum eintauchen und den Blick wieder auf den klassischen Projektmanager und dessen Aufgaben fokussieren. Einem Projektmanager bleibt in agilen Projekten und Modellen wie z.B. Scrum eigentlich nur die Wahl, sich für eine der Rollen (Scrum Master oder Product Owner) zu entscheiden. Die meisten wählen den Pfad des Scrum Masters – auf den ersten Blick scheint der Scrum Master mehr mit einem Projektmanager gemein zu haben als der Product Owner.

Die Entscheidung, ob der originäre Projektmanager ein Scrum Master oder Product Owner werden soll, ist meiner Meinung nach eine Frage des menschlichen Charakters und der Fähigkeiten. Die essentielle Entscheidungsgrundlage ist dabei die Erkenntnis eines wichtigen Unterschieds zwischen Scrum Master und Product Owner: Während der Scrum Master ein “Projektbegleiter” ist, ist der Product Owner ein “Projektführer”. Der eingangs erwähnte klassische Anspruch, das ein Projektmanager “Führungsaufgaben” übernimmt, wird in Scrum eher dem Product Owner zugeschrieben. Der Scrum Master allerdings ist der “Begleiter”. Er deckt die Sicht des Entwicklers auf den Projektmanager, worin dieser wie schon beschrieben nur “Miittel zum Zweck” oder eine Hilfskraft darstellt.

Ist also ein Projektmanager stark in den Disziplinen Kundenkontakt, Analyse, Steuerung, Budgetierung und hat das “Führungs-Gen”, dann sollte er sich mit der Rolle des Product Owners anfreunden. Ist er jedoch stark bei technischer Kenntnis, sozialem Umgang, Hilfsbereitschaft, Metriken und Dokumentation (siehe Servant Leadership), ist für Ihn wohl eher der Scrum Master ein geeignetes Tätigkeitsfeld.

Einsichten & Erkenntnisse

Aus all diesen Gedanken heraus erschließt sich für mich die Erkenntnis, das die klassische Rolle des Projektmanagers ausgedient hat – ja sogar mittel- bis langfristig zum Aussterben verurteilt ist. Denn für Software-Unternehmen ist es entscheidend, Projekte und deren Durchführung stetig zu verbessern – also besser steuern, kontrollieren und hervorsagen zu können. Die “Zertrümmerung” der Aufgaben, Wirkungsbereiche und Verantwortlichkeiten eines klassischen Projektmanagers in verschiedene, spezialisierte “Unter-Rollen” ist dabei für mich eine normale, evolutionäre Entwicklung. Die Dezentralisierung des Managements parallelisiert die Durchführung der Aufgaben, beschleunigt die Teilumsetzung bei gleichzeitiger Optimierung durch Spezialisierung.

Natürlich bleibt die Gefahr des Scheiterns bei diesem agilen Modell, ist aber durch die Diversifikation der Aufgaben auf die einzelnen Rollen im Vergleich zum klassischen Modell minimiert. Besonders herausfordernd sind die Bereiche Kommunikation und Koordination. Nur durch eine abgestimmte Kommunikation und einfache, prägnante Koordinationsregeln kann aus der Aufgabenteilung ein direkter positiver Effekt erreicht werden.

Für den “klassischen Projektmanager” heisst das nicht, das er schwere Zeiten vor sich hat. Im Gegenteil, Projektmanager können und sollten diese Entwicklung für sich nutzen und sich für die einzelnen Teilaufgaben spezialisieren. Zumindest gilt das für die operative Ebene. Für besonders kompetente und erfahrene Projektmanager tut sich ein neues Tätigkeitsfeld auf, denn durch die Dezentralisierung der Aufgaben entsteht der Bedarf des koordinierten Bündelns und Steuerns der operativen Teile aus der strategischen Ebene heraus.

Ich als Entwickler freue mich für meine Kollegen, denn für die Entwickler bedeutet dieser Schritt zur Optimierung des Managements mehr Verständnis und aktive, effektive Unterstützung auf Entwicklungsebene. Die Informationskanäle werden durch Konsolidierung geringer und man kann sich besser auf seine Aufgaben konzentrieren. Des Weiteren wird der Entwickler mehr in die Verantwortung für seine Tätigkeit genommen. In den meisten Fällen geht das einher mit einer gesteigerten Anerkennung der Leistung des Entwicklers bei gleichzeitiger Professionalisierung im Sinne von Mitwirkung, Kommunikation und Detailplanung.

Es bleibt spannend!