Es könnte alles so einfach sein: Wer macht Was bis Wann. Das ist klassisches Projektmanagement. Das Ziel des Projekts ist einigermaßen bekannt und stabil; der Weg dorthin ausreichend beschildert. Wenige Projektleiter planen, koordinieren und kontrollieren; viele Mitarbeiter führen aus: Planungsapartheid. Was aber wenn Ziele sich verändern oder sich erst im Laufe des Projekts formen, wenn der Weg sich als Sackgasse herausstellt oder erst ein Weg gefunden werden muss? Dann sind Kreativität und Innovation gefragt und zwar nicht nur die der Projektleiter.
Projekte sind Zwei-Klassen-Systeme: Wenige denken und lenken, der Rest führt aus. Unverkennbar die Parallele zur Organisation von Großunternehmen, insbesondere in der Industrie. Ich nenne diese Organisationsform deshalb industrielles Projektmanagement. Das vorrangige Ziel industriellen Projektmanagements ist die Effizienz. Wenig verwunderlich, denn dafür wurde das moderne Management schließlich erfunden. Unter bestimmten Rahmenbedinungen funktioniert industrielles Projektmanagement auch sehr gut. Nämlich dann, wenn die Komplexität so gering ist, dass die Kreativität der planenden Klasse ausreicht, um die auftretenden Hindernisse zu bewältigen.
Diese Grenze der durch wenige Führungskräfte beherrschbaren Komplexität haben wir in vielen Projekten, insbesondere in der IT, schon lange überschritten. Folgerichtig haben sich, wiederum insbesondere in der IT, Formen von postindustriellem Projektmanagement im letzten Jahrzehnt entwickelt. Vorrangiges Ziel dabei ist nicht mehr die Effizienz, sondern kreative Lösungen, Innovation und Anpassungsfähigkeit in instabilem Umfeld. Agilität heißt das Schlagwort (vgl. das Agile Manifest). Wesentliches Merkmal dieser postindustriellen Formen von Projektmanagement ist die Tendenz zur Selbstorganisation. Nicht nur weil es menschlichere Arbeitsbedingungen bedeutet, sondern weil die Weisheit der Vielen in unsicheren Situationen bessere Ergebnisse verspricht.
Wenn nun die planerischen, koordinierenden und kontrollierenden Tätigkeiten zunehmend selbstorganisiert durchgeführt werden, was wird dann aus dem Projektmanager? Ich meine: Hilfe zur Selbstorganisation. Die vorrangige Aufgabe eines postindustriellen Projektmanagers ist die Gestaltung eines temporären sozialen Systems, das in der Lage ist selbstorganisiert die Projektaufgaben zu bewältigen.
Bildnachweis
Das Artikelbild wurde von Paul Bailey unter dem Titel „bobby“ auf Flickr unter einer Creative-Commons Lizenz (CC BY-SA 2.0) veröffentlicht.
10 Kommentare
Mal ehrlich: mir ist das zu einfach. Sicher, Projektmanagement baut auf dem Operations Research des letzten Jahrtausend auf und ist heute in vielen Bereichen so – wie ursprünglich gedacht – nicht mehr anwendbar. Allerdings: es arbeitet doch heute wirklich kaum noch ein Projektmanager mehr so wie sie oben beschreiben! Ich arbeite in der Automobilindustrie, da wird natürlich auch viel geplant, aber das Produkt entsteht weitgehend in Selbstorganisation, da sind nämlich ganz viele Unternehmen daran beteiligt, denen ich gar nicht vorschreiben kann, was sie wann wie und so weiter tun müssen, die sind ja rechtlich autonom. Planung gibt da einen wichtigen Rahmen vor( Quality Gates) und synchronisiert die beteiligten Unternehmen, ohne das würde da nie ein Auto rauskommen… Und nun zur IT: da wird immer erzählt, dass die Softwareentwicklung so modern sei, und jetzt „post-industriell“, warum sind dann uralte Ansätze aus der Industrie wie z.B. KanBan gerade so en vogue??? Das ist mir echt zu viel Schwarz-Weiß gedacht, ist ja auch leicht, auf die anderen zu schimpfen… Wir müssen viel mehr die Anforderungen der Projekte verstehen und auf der Basis dann entscheiden, welches Projektmanagenent oder Führungsprinzip das richtige ist, das mag ja in vielen Fällen Selbstorganisation und agiles Vorgehen sein (z.B. in der Automobil-Vorentwicklung), in anderen Projekten oder Projektphasen passt es eben nicht, so wie situatives Führen eben auch richtiger ist als Laisser Faire oder Autoritär. Für mich lohnt sich da übrigens auch eher der Blick in das Zeitalter des Handwerks oder in das Improvisieren (z.B. im Free Jazz), da können wir wirklich lernen, wie wir künstlerisch, erfahrungsgeleitet und spielerisch neue Ansätze und Lösungen finden, soweit ist alles was ich bislang zum Agilen Projektmanagement gelesen und gehört habe bislang noch nicht gekommen (alter Wein in neuen Schläuchen?). Übrigens haben wir all das auf der letzten InterPM in Glashütten diskutiert und live den Improvisationskünstler Christopher Dell dazu erleben können…
Danke für den kritischen Kommentar. Ja, die Darstellung ist schwarz-weiß. Ganz bewusst. Natürlich arbeitet heute und schon lange niemand mehr nach dem ursprünglichen, hierarchischen, industriellen Projektmanagement. Vielleicht hat auch nie jemand so gearbeitet. Darum geht es mir aber auch gar nicht. Es geht mir um die damit verbundenen Glaubenssätze, die dem klassischen Management entstammen. Und einer davon ist die Zweiteilung der Aufgabe und Management und Ausführung. Was effizient ist und daher auch in bestimmten Situationen seine Berechtigung habe, in anderen aber eben nicht. Und da kommt für mich die Komplexität des Projekts und die Stabilität des Umfelds in Spiel. Meine Aussage ist letztlich: Je weniger komplex, je klarer die Anforderungen, je stabiler das Umfeld, desto eher funktioniert industrielles Projektmanagement und funktioniert dann auch effizienter. Insbesondere in der IT sind weder die Anforderungen klar, noch ist das Umfeld stabil. Daher haben sich meiner Meinung nach dort post-industrielle, agile Formen bisher am weitesten entwickelt. (Na gut, auch die leicht anarchistische Neigung vieler Informatiker hat das katalysiert.) Ich bin absolut der Meinung, dass Scrum keineswegs alter Wein in neuen Schläuchen ist. Scrum gibt der Selbstorganisation von Teams eine sehr klaren und strikten Rahmen. Es geht mir aber auch weniger um die konkrete Methode. Es geht mir darum, dass sich Glaubenssätze weiterentwickln hin zu mehr Selbstorganisation und weniger Planungsapartheid.
Ich lese heraus, dass die IT´ler die besseren (Projekt-)Manager sind. Das gilt es meiner Ansicht erst mal zu beweisen, viele Studien widerlegen das ja auch in regelmäßigen Abständen, und das Agiles Projektmanagement bessere Resultate bringt, hat mir auch noch keiner nachweisen können… Zugegeben, Selbstorganistion und agiles Vorgehen klingt modern, ist besser zu verkaufen als all das „klassische“ Vorgehen…
Aber was ist wirklich anders? Ja, mehr Kommunikation, kürzere Taktung, mehr Aktivität des Teams. Selbstorganisation sieht für mich aber anders aus – siehe mein Vergleich zu Freejazz – kein Takt (Daily Scrum), keine Vorgaben (Product Backlog, Product Owner…), wirkliches einfühlen, sich individuell aufeinander abstimmen, um zu wirklich innovativen Lösungen Performances zu kommen. Deshalb bleibe ich bei meiner These, dass Scrum nur „alter Wein in neuen Schläuchen“ ist. In der Praxis erlebe ich eh, dass Agiles Vorgehen in Reinform eher selten praktiziert wird, üblicher sind Mischformen oder agil-traditionelles Vorgehen. Für mich fehlt auch eine differenzierte Betrachtung, bei welchen Projekten / Anforderungen das agile Vorgehen überhaupt sinnvoll ist, und wann eben nicht. Nur so kommen wir weiter, nicht aber mit der plumpen Behauptung „agil ist besser“ ;-)
Keineswegs wollte ich die IT’ler als die besseren Projektmanager darstellen. (Wenn man sich die verheerenden Ergebnisse der Studie von McKinsey und Oxford vor Augen führt wäre das auch vermessen.) Ich denke allerdings, dass in IT-Projekten aus zweierlei Gründen mehr mit innovativen Konzepten für Projektmanagement experimentiert wird: erstens, weil der Projektgegenstand rein digital ist und mehr Experimente der Zusammenarbeit erlaubt und zweitens, weil durch den Fachkräftemangel von den Mitarbeitern mehr Management-Innovation gefordert wird.
Was anders ist in agilen Ansätzen? Ich bin sicherlich kein Experte in agilen Vorgehensweisen, aber betrachten wir die einfache Frage wer über den Plan und die Vorgehensweise im Projekt entscheidet. Im klassischen Projektmanagement sind das immer wenige an der Spitze. In Scrum ist klar geregelt, dass das Team allein die Entscheidung trifft und verantwortet (unter gewissen Rahmenbedingungen). In der täglichen Projektarbeit mag das wie alter Wein in neuen Schläuchen ausschauen, tatsächlich ist es aber eine völlig andere Grundhaltung dem Team gegenüber.
Ich bin mir nicht sicher, ob weniger stringente Regeln (Takt, Product-Backlog, etc.) einen Vorteil brächten. Das wäre aber tatsächlich eine interessante Untersuchung: Wie viel Regeln und Prozesse braucht Selbstorganisation. Ich denke dabei immer in wenig an Brainstorming, wo eine Fokussierung auf ein Thema und einige wenige Regeln wesentlich zu guten Ergebnissen beitragen.
Projektmanagement wird als Management (Auftrag klären,Planen, Steuern, Überwachen) immer seine Bedeutung haben und sich im Kontext aktueller Anforderungen professionalisieren. Und da ist Agilität eine Antwort, die bewährte Konzepte der Teamsteuerung, Gruppendynamik und kollektiver Problemlösetechniken so übersetzt hat, dass es in der Profession Projektmanagement ankopplungsfähig ist.
Wer z.B. schon einige Zeit mit LEAN Prozessen und deren Einführung zu tun hat, findet an „agilen Methoden“ wenig Alleinstellung. Da ist die Industrie selbst dann schon postindustriell (um bei Deiner Nomenklatur zu bleiben :-) ).
Etwas ganz anderers ist, dass im PM viel zu häufig noch Management mit Führung verwechselt wird – aber das wäre ein eigener blog: http://www.hinz-wirkt.de/lotsenblog/artikel/46-komplex-ist-nicht-kompliziert
Ok, auch in dem von Ihnen „klassischen PM“ plant der Projektmanager nicht allein, das kann er ja schon aufgrund der meist fehlenden technischen Fachkenntnisse nicht, der Projektmanager organisiert den Planungsprozess, z.B. in einem Planungsworkshop (bei Siemens ist das z.B. ein PACT-Workshop, das steht für Project Accelaration by Coaching & Teamwork). Dort wird also die Planung gemeinsam erarbeitet, ein Coach unterstützt dabei, der PM muss natürlich zum Schluß das letzte Wort haben, weil ja die Planung nicht im luftleeren Raum stattfindet, sondern sich an den Wünschen der Kunden und weiteren Stakeholdern orientieren muss. Das ist m.E. in Scrum nichts anderes, auch hier gibt es natürlich einen Rahmen, den das Team im Zusammenspiel mit dem Product Owner füllen muss. Eine zentrale Frage ist aus meiner Sicht, wie Entscheidungen zustande kommen. Das ist eh eine der zentralen Fragen im Projektmanagement. Das hat auch was mit Haltung, Wünschen oder Erwartungen der Teammitglieder und des Projektmanagers zu tun, im Wesentlichen geht es da aber um eine generelle Machtfrage. Wie viel Macht hat ein Projektmanager und wie er das Team dann ein? Da sehe ich wenig Unterschiede in „klassischem“ oder „agilem“ Projektmanagement. Es kommt vielmehr auf den Kontext und die Führungskultur im Unternehmen an. Hier sehe ich durchaus Unterschiede zwischen der angestammten Industrie und der Software„industrie“, letztere sind nämlich meistens kleinere Unternehmen mit wenig Hierarchien, die dann auch eine andere Kultur haben (können), je größer das Unternehmen wird, umso schwieriger sind dann auch die Machtfragen zu lösen…
Ich räume ja gerne ein, dass meine Darstellung extrem Schwarz-Weiß ist. In der Praxis kenne ich auch eher Grauschattierungen: natürlich plant der Projektmanager nicht ohne sein Team; das kann ich in den allermeisten Fällen ja gar nicht. Sie haben recht: Die zentrale Frage ist wer die Macht hat, Entscheidungen zu treffen. Auch in dieser Frage gibt es in der Praxis beliebige Grauschattierungen zwischen strikt-hierarchischen Entscheidungsprozessen und demokratischen Entscheidungsprozessen im Team. Was bei welchem Projekt funktioniert, ist nicht zuletzt auch eine Frage der Kultur in der Organisation die dieses Projekt durchführt. Darum sehen wir agile Vorgehensweisen eher bei produktorientierten SW-Unternehmen, die intern arbeiten können wie sie wollen, als bei dienstleistungsorientierten SW-Unternehmen, die Individual-SW für große Industrieunternehmen bauen.
genau: es braucht unentscheidbare Entscheidungen, denn die Entscheidbaren hat die Organisation längst in Form von Prozessen, Handbüchern, Standards und Leitlinien geregelt.
Und dann kommen wir auf das Thema Projektmanagement und die Frage, ob die PM Profession nicht langsam zu viel Energie in die Optimierung der entscheidbaren Entscheidungen legt und wenig achtsam gegenüber den unentscheidbaren ist. Sie ist für mich ‑zugegeben- rhetorisch, denn nach meiner Beobachtung wird zu viel in das erstere investiert.
Junge PM Organisationen sollten natürlich zunächst Ihre Basis gestalten und in professionelle Strukturen (PM Prozesse, PM- Handbüchern, Training von Standards und Methodik) investieren. Reife PM Organisationen müssen aber auch den Überbau entwickeln und ein PM jenseits der Tools & Checklisten beginnen:
Wer so agiert, missbraucht Planungstools und PM-Modelle nicht mehr, um die Kom-plexität auszublenden, sondern nutzt sie als Werkzeug, um das Projekt effektiv zu steuern. Vor allem aber zeigt er eine Haltung, die von Neugier, Risikobewusstsein und der Bereitschaft, unentscheidbare Entscheidungen zu treffen, geprägt ist.
Dabei unterscheidet sich diese Führungskraft vor allem in vier Punkten von seinem Kollegen, der immer noch Heldenkämpfe ficht:
Er arbeitet mit Beschreibungen, anstatt von einer „objektiven Wahrheit“ auszugehen.
Er denkt in Alternativen, anstatt nach eindeutigen Lösungen zu suchen.
Er setzt auf Vernetzung statt auf linearen Kausalketten.
Er entscheidet unter Risiko, anstatt bei unerwarteten Situationen entscheidungsunfähig zu sein.
Mit diesen Anforderungsebenen souverän umzugehen, ist die große Herausforderung. Genau das ist der Grund, warum ich bei Projektleitung gerne von der Königsdisziplin der Führung spreche…
Interessanter Gedankengang und Blickwinkel: Entscheidbare und daher optimierbare Entscheidungen versus unentscheidbare Entscheidungen. Projektmanagement als Königsdisziplin der Führung finde ich sehr schön. Wäre doch ein tolles Thema für ein open-space auf dem PM-Camp in Dornbirn im November, oder? Wir sammeln die Themen ganz lose in Google Moderator; ich habe es schon hinzugefügt.
und ich mich schon angemeldet; gern mache ich einen Input zu
wirksames PM braucht keine Helden, sondern gute Führung