Es gibt kein nicht-agiles Projektmanagement

Erste Verwechslung: Das Wasserfall-Modell wird mit Projektmanagement gleichgesetzt

Das mag jetzt für manchen eine Spitzfindigkeit sein: Das Wasserfallmodell, quasi das Ur-Gegenstück aller agiler Vorgehensmodelle, ist eben ein solches, ein Vorgehensmodell. Es hat insofern nur etwas mit Projektmanagement zu tun, dass ich es innerhalb eines Projekts nutzen kann, um mein Vorgehen inhaltlich und zeitlich zu strukturieren. Die Verquickung unter dem Dach „Projektmanagement“, so mein Verständnis, kommt daher, dass der Begriff Projektplanung irgendwann in diesem Modell gelandet ist.

Ein Projekt allerdings hat zwei unterschiedliche Perspektiven: da ist zum einen der Inhalt des Projekts, der Projektgegenstand. Dessen Erstellung wird durch Vorgehensmodelle beschrieben. Zum anderen gibt es organisatorische Notwendigkeiten, etwa die Abstimmung, wer welche Aufgabe nach welcher Systematik übernimmt und wie dessen Verfügbarkeit sichergestellt wird. Diese beiden Aspekte wurden durch die Aufnahme der Planung in das Wasserfallmodell vermischt.

Zweiter Irrtum: Pläne müssen eingehalten werden

Über dieses Thema hatte ich an anderen Stellen bereits mehrfach geschrieben. Der Artikel „Bitte hört auf Termine einzuhalten!“ war besonders beliebt. Und ehrlich: ich weiß nicht, wer wann aus welchem Grund auf die Annahme gekommen ist, man könne Pläne einhalten. Wir müssten Hellseher sein, um Pläne einhalten zu können. Wer also behauptet, ein Plan sei deshalb nicht agil, weil er starr sei, hat meiner Meinung nach den Sinn von Planung nicht verstanden.

Jeder von uns macht ständig Pläne. Wir überlegen, wie wir unseren Tag gestalten wollen – und selbstverständlich wird es Störungen und Abweichungen geben. Wir überlegen, wie der nächste Urlaub aussehen soll und was wir vorbereiten müssen – und selbstverständlich wird es Störungen und Abweichungen geben. Außerdem werde ich im Projektverlauf klüger. Beides sollte Eingang in meine Planung finden.

Die Weiterentwicklung des Plans, oder besser: des Vorgehens, muss der Normalzustand sein und deshalb mit möglichst wenig Aufwand einhergehen.

Wobei genau genommen der Plan gar nicht geändert werden muss. Vielmehr wird dem Plan die Realität gegenübergestellt. Aus dem Delta können wir lernen.

Sobald ich jedoch nicht alleine bin, sollte ich eine gewisse Systematik haben, nach der wir von den Anpassungen erfahren und uns beteiligen können. Warum? Weil uns Pläne helfen, dass uns unsere Arbeit leichter von der Hand oder besser: Hand in Hand geht. Pläne sind auch das Ergebnis von Abstimmung. Wenn jemand ein Gantt-Diagramm erstellt, ist das nichts anderes, als die Dokumentation dessen, wie wir vorgehen wollen.

Allerdings habe ich auch gelernt, dass diese Pläne oft als Terminpläne erstellt werden. Abhängigkeiten werden nur grob betrachtet. Und es werden Dinge geplant, die man heute noch nicht weiß. Wenn jemand das erlebt hat, kann ich gut verstehen, dass er diese Form von Planung als starr erlebt hat und deshalb ablehnt. Dann kommt agil als Segen daher. Fußt dann jedoch auf einem Irrtum, denn das ist keine gute Projektplanung. „Projektplanung ist Denken“ ist ein weiterer Artikel, in dem ich darauf eingehe.

Wobei ich eine Sache festhalten will: Die Diskussion, die dank „agil“ angestoßen wurde, halte ich für sehr fruchtbar. Auch denen, die Pläne als „einzuhalten“ definiert haben, wird dadurch nach und nach bewusst, dass das so nicht sein muss. Gar nicht sein darf. Pläne sind Hilfsmittel für gute Zusammenarbeit.

Projektmanagement ist eine Sammlung von Hilfsmitteln, die es uns leichter machen, gut zusammenzuarbeiten. Punkt.

Eine dritte Gefahr: Die Weiterentwicklung von Software wird als Projekt betrachtet

Was ist ein Projekt?

Diese Frage kommt mir in der aktuellen Debatte zu kurz. Wenn wir im Spannungsfeld zwischen Routineprozessen (definierte Aufgabenstellungen, viele Wiederholungen, stets dasselbe produzieren, identische Abfolge von Tätigkeiten, gleichbleibende Verantwortung) und Projekten (neuartig, einmalig, unbekannte Aufgabenstellung, unbekannte Mitstreiter unterschiedlicher Disziplinen, unklare Verantwortung und Tätigkeiten) handeln, erfordert das einen reflektierten Umgang mit der jeweiligen Ausgangslage. Projekte erfordern eine andere Organisation als Routineprozesse. Bei Routineprozessen wird einmal für viele Wiederholungen organisiert, bei Projekten individuell für das einzelne Vorhaben.

Als agil bezeichnete Vorgehensweisen sind besonders häufig in der Softwareentwicklung anzutreffen. So meine Wahrnehmung. Dort funktioniert etwa Scrum unglaublich gut. Auch das meine Wahrnehmung. Softwareentwicklung wird als Projekt bezeichnet. Also wird daraus gefolgert, dass man dieses Vorgehen mühelos auf andere Projekte übertragen kann. Dabei ist Softwareentwicklung meist gar kein Projekt.

„Kein Projekt?“, höre ich jetzt die Frage schon laut im Raum stehen. Ja, kein Projekt. Die häufigsten Fälle, die mir begegnet sind, werden als Projekte bezeichnet und sind keine. Was als „Softwareentwicklung“ bezeichnet wird, ist meist eine „Software-Weiterentwicklung“. Hier noch eine Funktion dazu, dort noch eine Komponente. Das ist eher ein kontinuierlicher Prozess des „Funktionen-Hinzufügens“, der sich nur dadurch von der Automobilproduktion unterscheidet, dass die Inhalte der Tätigkeiten, also die Funktionen selbst andere sind. Die Vorgehensweise ist wiederholend. Ein reines Projekt ist ein solches Vorhaben nicht.

Diesen Unterschied sollte man sich bewusst machen, bevor man beginnt, Methoden zu übertragen. Die Softwareentwicklung in dieser Form hat einen höheren Standardisierungsgrad der Abläufe als etwa die Implementierung einer Geschäftsmodellinnovation. Erst wenn wir uns bewusst machen, wo die Unterschiede liegen, wird ein sinnvolles Übernehmen von Vorgehensmodellen möglich.

„Entspannt Euch!“

„Entspannt Euch!“, will ich rufen, denn Pläne sind keine Wahrheit und Lernen muss jeder. Was als Gegenteil von agil ins Feld geführt wird, ist das Ergebnis von Missverständnissen und Kontrollenthusiasten. Das, was im Moment als „klassisches Projektmanagement“ bezeichnet wird, ist schlicht eine Sammlung von Hilfsmitteln, die uns das Organisieren von guter Zusammenarbeit erleichtern. Diese Organisationsleistung benötigen wir, um neue, unbekannte Aufgabenstellungen anpacken zu können. Die dürfen dann gerne auch komplex sein.

Wir sollten dann nur anerkennen, dass wir zu Projektbeginn noch nicht alle Antworten kennen und deshalb keinen Plan für das gesamte Vorhaben machen können. Wir verwenden in Projektplänen gerne drei Fragezeichen als Symbol für die Bereiche, von denen wir noch keine Ahnung haben. Logische Konsequenz? Müssen wir uns wohl Ahnung beschaffen. Und warum drei Fragezeichen? Weil wir in Dokumenten leichter danach suchen können. Das macht uns die Arbeit leichter.

Die Methode „Projektmanagement“ selbst fordert nicht deren Einhaltung. Das sind stets die Menschen im Umfeld eines Vorhabens. Deren Einstellung und Haltung sind es, die aus einem Werkzeug ein Kontrollinstrument machen – oder eben ein nützliches Werkzeug. Dass sich an der Haltung vieler Beteiligter etwas ändern könnte, das wird vermutlich der große Verdienst derjenigen sein, die heute so vehement agil fordern und als Gegner klassischen Projektmanagements auftreten.

Wie bei jeder kleinen handwerklichen Tätigkeit auch, verwende ich Werkzeuge im Projektmanagement nur dann, wenn sie mir von Nutzen sind, mein Leben und das meiner Mitstreiter leichter machen etwa. Das was im Moment als „agil“ betitelt wird, fügt dieser Sammlung neue Werkzeuge hinzu oder manchmal auch schlicht eine neue Perspektive auf ein bekanntes Instrument. Die Werkzeugkiste des Projektmanagements wird umfangreicher.

Und was bei der ganzen Sache irgendwie logisch ist: Wer erst lernt, nachdem das Projekt bereits abgeschlossen ist, lernt zu spät. Das gilt völlig unabhängig von der Wahl des Vorgehensmodells.

zur Übersicht

Der Projektstart: ‚Onboarding‘ für die Mitstreiter

Wen ins Team holen? Auch Chefs sind Mitstreiter.

Ein Problem, das immer wieder auftaucht, entsteht durch den hierarchischen Aufbau vieler Organisationen. Auch Projektleiter denken in „oben“ und „unten“. Weshalb es leicht vorkommen kann, dass die Chefs, „die da oben“, außen vor bleiben. Was auf erster Näherung auch Sinn macht, denn es sind ja die Chefs, nicht die operativen Kräfte.

Allerdings kennt das Projekt als Organisationsform erst einmal keine Hierarchie. Der Projektleiter wird engagiert, um etwas zu liefern, was die Routine und was die Standardabläufe in einem Unternehmen nicht liefern können. Das kann er nicht alleine tun, weshalb er Mitstreiter braucht. Diese Mitstreiter benötigen ein bestimmtes, für das Projekt erforderliches Know-how und, solange wir in einer hierarchischen Organisation arbeiten, auch die notwendige Entscheidungskompetenz. Die haben im Normalfall die Chefs in der Linie. Weshalb es Sinn macht, sie in die Arbeit am Projekt zu integrieren.

Diese Erkenntnis ist nicht wirklich neu und sicherlich nicht bahnbrechend. Sie ist insofern jedoch spannend, da mit dieser Aussage soeben die Chefs zu Mitstreitern im Projekt wurden. Damit verlässt das Projekt als temporäre Organisationsform die Strukturen der Linienorganisation (siehe auch „Wer von Abteilungen redet, denkt nicht in Projekt„). Die Hierarchie, wie sie im Organigramm des Unternehmens beschrieben ist, gilt im Rahmen der Arbeit am Projekt nicht mehr. Das ist mindestens gewöhnungsbedürftig für alle Beteiligten. Dann sitzt der Boss als Teammitglied am Tisch. Darf er jetzt immer noch bestimmen? Wie soll er sich verhalten?

Wird diese Situation, dieser Rollenkonflikt, von den Beteiligten nicht angesprochen und geklärt, führt das nicht selten zu unnötig viel Arbeit und Verantwortung für die Führungskräfte. Ohne dass darüber geredet wird, wird von den Führungskräften im Projekt dasselbe erwartet, was in der Linie von ihnen erwartet wird: sie sollen die Führung übernehmen. Der Projektleiter schaut darauf, was die Chefs sagen und degradiert sich im Extremfall selbst zum Erfüllungsgehilfen. Einem teuren und sicherlich bald auch demotivierten Erfüllungsgehilfen, wohlgemerkt.

Erwartungen, Kompetenzen, Spielregeln: Rollen klären ist unabdingbar.

Macht man sich bewusst, dass ein Projekt sich zwar in der Hierarchie des Unternehmens bewegt, jedoch die Organisation des Projekts im Innenverhältnis mit dieser Hierarchie zunächst einmal nichts zu tun hat, wird der Hinweis auf eine notwendige Rollenklärung banal. Dann sitzt da zwar noch dieselbe Person am Tisch, die in der Linie Chef des Projektleiters ist, allerdings diesmal in einer anderen Rolle. Das Know-how und die Kompetenzen dieser Person werden im Projekt benötigt, nicht der Chef als Funktion.

Aus diesem Grund lohnt es sich drei Stichworte auf die Agenda der ersten Besprechungen zu setzen:

Erwartungen, Kompetenzen und Spielregeln.

  • Was erwartet im Rahmen des Projekts wer von wem?
  • Welche Kompetenzen werden wem zugestanden, etwa wenn es um Entscheidungen geht?
  • Und welche Spielregeln im Sinne von übergeordneten Prinzipien sollen für die Zusammenarbeit gelten, etwa wenn es darum geht, Entscheidungen zu treffen?

Ob es sich dabei um ein informelles Treffen in kleiner Runde handelt, oder einen offiziellen Projektstart-Workshop, spielt dabei keine Rolle. Die Fragestellung sollte jedes Mal auf der Agenda stehen, wenn Mitstreiter teilnehmen, für die diese Fragen bisher nicht beantwortet wurden.

Wir verwenden übrigens bewusst nicht die „AKV“, die Aufgaben, Kompetenzen und Verantwortung. Das Besprechen der üblicherweise unausgesprochenen Erwartungen sowie der damit verbundenen Spielregeln der Zusammenarbeit, die den Umgang mit den Erwartungen beschreiben, ist deutlich wirkungsvoller für eine gute Zusammenarbeit. Damit werden auch Themenfelder handhabbar, die zu Projektbeginn noch gar nicht erkannt werden können und deshalb erst später identifiziert werden. Aufgaben und Verantwortung sollten sich aus der Projektplanung ergeben. Die Erstellung des operativen Projektplans steht erst später auf der Agenda, nachdem die Projekteinrichtung vollzogen ist. Schafft die Planung diese Klarheit nicht, hat sie den Namen nicht verdient. Das gilt bei agilen Ansätzen ebenso, wie bei allem, was in die Schublade „klassisch“ gepackt wird.

Nicht außer Acht sollte man beim Projektstart die Führungskräfte der Personen, die am Projekt mitarbeiten. Diese indirekten Mitstreiter sollten ebenfalls Klarheit und Verlässlichkeit darüber haben, in welchem Rahmen und nach welchen Spielregeln ihre Kollegen, sprich: ihre Mitarbeiter im Fachbereich, im Projekt eingesetzt werden sollen. Die sind schließlich ihre „Untergebenen“, um in der Sprache hierarchischer Organisationen zu bleiben. Wer als Projektleiter immer wieder Schwierigkeiten damit hat, dass die Chefs der Teammitglieder sich in das Projekt einmischen, der kann davon ausgehen, dass eine weitere Rollenklärung zu weniger Spannungen führen wird. Rollenklärung wird so lange betrieben, bis für alle Beteiligten Klarheit und Akzeptanz erreicht sind.

Projektteams benötigen eine Strategie, um mit Konflikten konstruktiv umgehen zu können

Man müsste allerdings Hellseher sein, um bereits beim Projektstart alle Mitstreiter identifizieren und deren Rollen zu 100 Prozent klären zu können. Nicht nur deshalb muss man davon ausgehen, dass es Konflikte geben wird. Die entstehen meist, weil zwei unterschiedliche Erwartungen aufeinander treffen. Was nicht schlimm ist, sofern der Konflikt geklärt wird.

Ein Projektteam wird umso produktiver zusammenarbeiten können, je mehr es in der Lage ist, Konflikte selbst und zügig ausräumen zu können. Deshalb lohnt es sich auf Spielregeln für die Konfliktlösung besonders zu achten:

  • Wie wollen wir damit umgehen, wenn wir einen Konflikt erkennen?
  • Wie sprechen wir ihn an?
  • Wie gehen wir die Lösung an?
  • Wer soll, kann und darf in welcher Form daran mitwirken?

Konflikte sind normal. Wer weiß, wie er sie lösen kann, tut sich leichter, sich auf die notwendigen Ergebnisse zu fokussieren.

Allein die gemeinsame Auseinandersetzung mit diesen Fragen wirkt Wunder auf die Zusammenarbeit. Damit werden Konflikte normal, es ist in Ordnung, wenn welche auftreten, was sie besprech- und damit lösbar macht. Wobei am Ende der Diskussion im Idealfall klare Spielregeln formuliert sind, die alle Beteiligten akzeptiert haben.

Das vorläufige Projektteam als Mittel des Brückenbaus

Und wie kommt man nun zum Projektteam? Nicht in einem Schritt. Das lehrt die Erfahrung. Selten sind Organisationen so klar aufgestellt, dass bereits mit Erteilung des Projektmandats das Projektteam benannt werden kann. Ganz abgesehen davon, dass Projekte zu diesem Zeitpunkt selten so klar umrissen werden können, damit dies gelingt.

In der Startphase ist deshalb diplomatisches Geschick gefragt. Der Weg über ein „vorläufiges Projektteam“ kann helfen, die Lücke zu schließen, die zu Beginn oft entsteht. Der Projektleiter bittet in diesem Fall die Fachbereiche darum, einen Experten in das vorläufige Team zu entsenden, das lediglich die Projekteinrichtung vollziehen soll. Die Zusage dafür fällt dem Fachbereich leichter, als einen Experten für das gesamte Projekt zu entsenden, wo doch der Umfang der Mitarbeit noch nicht annähernd klar ist. Angefragt wird der Experte für das vorläufige Team schließlich lediglich für ein paar Stunden oder Tage zur Mithilfe an der Projekteinrichtung, nicht für monatelange Mitwirkung am Vorhaben über die nächsten zwei Jahre hinweg. Mit dieser Vorgehensweise unter Einrichtung eines vorläufigen Projektteams hat sich das eingangs erwähnte Henne-Ei-Problem erledigt.

Die so für die Projekteinrichtung gewonnenen Experten versuchen dann gemeinsam mit der Projektleitung so viel Klarheit über das Vorhaben zu schaffen, wie nur irgendwie möglich. Das Ergebnis kann eine Projektskizze sein, die eine grobe Planung des Vorhabens und erste inhaltliche Gedanken enthält. Diese Projektskizze dient der Abstimmung mit den Auftraggebern des Projekts über die Vorgehensweise und die Ausstattung des Vorhabens. Jetzt ist es erstmals möglich den Umfang und die Bedarfe des Projekts abzuschätzen, so dass nun tatsächlich geklärt werden kann, wer in welchem Umfang und unter welchen Spielregeln für die weitere Zeit ins Projekt entsendet wird.

Im Idealfall werden diejenigen Experten weiter am Projekt mitarbeiten, die bereits an der Einrichtung mitgewirkt haben. Das spart Schleifen für die Abstimmung. Allerdings ist es utopisch anzunehmen, dass dies jedes Mal gelingt. Weshalb ein gewisses Maß an Wiederholung der Projekteinrichtung eingerechnet werden sollte, damit den später hinzukommenden Mitstreitern die Chance bleibt, das Vorhaben zu verstehen sowie die Vorgehensweise zu akzeptieren und mitzutragen. Anpassungen der Vorgehensweise an die Bedürfnisse der neuen Mitstreiter sollten deshalb als Normalfall betrachtet werden, der die spätere Arbeit in der Umsetzungsphase deutlich erleichtert.

Die Projekteinrichtung ist ein Gemeinschaftswerk

Ein Projektstart-Workshop als erste Besprechung des vorläufigen Projektteams ist ein bewährtes Mittel, um einen soliden und zügigen Einstieg in die Projektarbeit zu machen. Darin wird über

  • Ausgangslage,
  • Risiken,
  • Ergebniserwartung,
  • zu bearbeitende Themen,
  • anvisierte Zwischenergebnisse sowie
  • Rollen,
  • Kommunikation und
  • Informationsflüsse gesprochen.

Im Idealfall arbeitet der Auftraggeber daran (in Teilen) mit, denn oft kennt er alleine die Vorgeschichte und die wesentlichen Anforderungen. Die Vorgehensweise bei Scrum, in der der Product Owner am Einstieg in die Planung mitwirkt, trägt genau dieser Tatsache Rechnung.

Das gemeinschaftliche Erarbeiten der Vorgehensweise bringt mehrere Vorteile mit sich. So wird zum einen das gesamte Know-how der beteiligten Experten genutzt, was in den meisten Fällen zu einer schlüssigeren und belastbareren Vorgehensweise führt. Zum anderen entlastet dieses Vorgehen sehr häufig den Projektleiter von der gefühlten Erwartung, alles alleine liefern zu müssen. Der Projektleiter ist eine Art „Dienstleister für gute Zusammenarbeit“ für sämtliche Beteiligte. Wird in einem solchen Workshop die gesamte Arbeit sichtbar gemacht, die ansteht, wird jedem Beteiligten klar, dass das nicht der Projektleiter alleine lösen kann.

Das alles zusammen führt wiederum zu einer viel höheren Akzeptanz für das Vorgehen bei allen Beteiligten, womit sich die Energie und die Diskussionen auf Lösungen und Ergebnisse konzentrieren können. Endlose Diskussionen warum was wie nicht geht und wer was wie falsch gemacht hat, sollten damit deutlich weniger werden. Unterm Strich antworten viele Teams, die so ins Projekt einsteigen, dass die Zusammenarbeit viel mehr Freunde macht und das unter anderem deshalb, weil die Teams weit besser vorankommen.

zur Übersicht

Persis User-Tipps

Auf den folgenden Seiten bieten wir Ihnen hilfreiche Informationen zur Persis-Produktfamilie. Die User-Tipps sind eine Sammlung von Beschreibungen und Anleitungen rund um Ihre Anwendungen. Die Inhalte werden von uns regelmäßig erweitert, um Ihnen so aktuelle Möglichkeiten der Lösungen näher zu bringen.

Tippen Sie einfach auf den unten stehenden Button und Sie gelangen zu nützlichen „User-Tipps“. Es öffnet sich eine weitere Seite in einem neuen Browserfenster bzw. Tab.
ANMELDUNG ERFOLGT ÜBER DEN GASTZUGANG AM ENDE DER LOGIN-SEITE!

Persis User-Tipps

Projektführung anstatt Projektmanagement?

Worte bestimmen, was wir erwarten

Warum die Wortklauberei? Weil Worte unseren Erwartungshorizont bestimmen. Wir hören „Projektmanagement“ und haben sofort eine Vorstellung davon, um was es sich dreht. Leider häufig eine unpassende, eine die mit Kommando und Kontrolle verbunden wird, was nicht zuletzt teilweise in der Blogparade zu „Beyond Project Management“ aus dem Jahr 2014 deutlich wurde. Hinterfragt man die mit dem Begriff „Projektmanagement“ verbundene Vorstellung, ähnelt diese häufig eher den Ideen von Taylor und Ford. Die beiden Herren wollten jedoch dasselbe Produkt immer wieder und dazu noch günstig herstellen. Im Projekt geht es darum nicht, es geht vielmehr darum, etwas bisher Unbekanntes überhaupt irgendwie zu realisieren.

Außerdem wird der Begriff „Projektmanagement“ häufig mit einer Sammlung von Projektmanagement-Werkzeugen verbunden, die in Projekten zum Einsatz kommen. Die Anwendung der Werkzeuge steht im Fokus, manches Mal nahe am Zwanghaften. Was durchaus seine Berechtigung haben mag, jedoch nicht Sinn und Zweck ist. All diese Instrumente sind letztlich Hilfsmittel, um die von einem Projekt erwarteten Ergebnisse leichter und mit höherer Sicherheit zu erreichen. Ist von Projektmanagement die Rede, wird schnell vergessen, dass es sich dabei schlicht um eine Sammlung bewährter Instrumente handelt. Alternativen sind zulässig, Anpassungen und Weiterentwicklungen nicht ausgeschlossen.

Derselbe Effekt tritt ein, wenn wir von „Projektleitern“ sprechen. Nicht selten wird damit die Person gemeint, die das Vorhaben im Sinne eines Fachexperten vollständig verstehen kann, weshalb sie in der Lage ist, alle Beteiligten anzuweisen und Entscheidungen zu treffen. Genau diesen Typ Projektleiter benötigen wir nicht mehr, denn wenn wir von echten Projekten sprechen (1), dürfen wir davon ausgehen, dass wir etwas tun, was ein einzelner Mensch nicht mehr in seiner Gesamtheit verstehen kann. Er ist auf eine gute Zusammenarbeit von verschiedenen Experten angewiesen.

Womit der Begriff „Projektführung“ beginnt Sinn zu machen – wenn er so verstanden wird, dass die Führungskraft die Aufgabe hat, diese gute Zusammenarbeit zu organisieren. Es geht darum, gemeinsam ein (soziales) System zu schaffen, das in der Lage ist, die gesteckten Ziele zu erreichen. Die „Projektführung“ hat für diese durchaus kreative Gestaltungsaufgabe jedoch keine Machtmittel im klassischen Sinne zur Verfügung. Sie kann immer einwirken, jedoch nie bestimmen.

Projektführung ist vor allem Organisation von Zusammenarbeit

Genau diese Gestaltung des Systems, die Organisation von Zusammenarbeit, ist es, die über den Erfolg entscheidet von Vorhaben, die eine einzelne Person nicht mehr verstehen kann. Wenn es gelingt, dass die Experten Hand in Hand arbeiten, dass sie Informationen sinnvoll und schlüssig an die passende Person weitergeben, dass sie Ideen verwerfen oder anpassen, dass sie gemeinsam weiterentwickeln, dann kann Neues entstehen. Entsprechend gehört zur Aufgabe der Projektführung Vertrauen entstehen zu lassen, eine passende Projektkultur zu schaffen, ein Klima entwickeln zu lassen, das Eigenverantwortung fördert – und fordert.

Projektführung muss dabei zwangsläufig davon ausgehen, dass sie nichts weiß. Selbst die Experten wissen nur über Vergangenes und müssen nun die Haltung von Lernenden einnehmen, die sich gemeinsam auf den Weg machen, um neue Erfahrungen zu generieren und daraus Projektergebnisse zu entwickeln. Weshalb Projektführung auch als das Gestalten eines gemeinsamen Lernprozesses verstanden werden kann. Dieses gemeinsame Lernen und Wirken benötigt eine Instanz, die für die Spielregeln der Zusammenarbeit sorgt, die Hindernisse – wie etwa Konflikte – aus dem Weg schaffen hilft, die es den Experten ermöglicht, sich auf ihre Expertenrolle einlassen zu können.

Der Projektführer ist Dienstleister für alle Beteiligten

Mit dieser Verantwortung wird der Projektführer zum Dienstleister für gute Zusammenarbeit. Er versucht zwischen den verschiedenen Interessen der Beteiligten zu vermitteln, diese auszubalancieren. Seine Basisstrategie bedingt, dass er verhandelt und vereinbart. Das setzt wiederum voraus, dass er die Menschen sieht, die beteiligt sind, und deren Besonderheiten.

Wer nun im Kopf hat, dass über diesem Projektführer noch die Geschäftsleitung wacht, sollte mit sich selbst noch in Klausur gehen. Genau das ist hiermit nicht gemeint. Der Projektführer führt alle Beteiligten zum Ergebnis, indem er moderiert, koordiniert, visualisiert, sichtbar macht, Vereinbarungen trifft und Abweichungen gegenüber Vereinbarungen anspricht, für geeignete Reaktionen sorgt, ohne anzuweisen und ohne diese selbst entwickeln und durchführen zu können. Das gilt auch für die Geschäftsleitung, die letztlich als Auftraggeber fungiert. Das gilt ebenso für diejenigen, die einen Pool von Experten vorhalten und zu denen wir heute wohl Abteilungsleiter sagen würden. Und das gilt für alle Beteiligten, die keinen Arbeitsvertrag mit dem eigenen Unternehmen haben, weil sie freiberuflich mitwirken oder beim Lieferanten oder Kunden angestellt sind. Projektführung hört nicht an der Unternehmensgrenze auf.

Bleibt die Frage, ob Projektführung hierfür der geeignete Begriff ist – im Sinne, dass er hilfreich und nützlich ist, um sich von alten Vorstellungen zu lösen? Vielleicht wäre auch „project leadership“ geeignet? Oder etwas ganz anderes? Wie auch immer: Hauptsache es hilft uns, uns von dem Bild eines hierarchischen Organisationsansatzes zu lösen. Der passt im Moment eher dort, wo Taylor und Ford nach wie vor gute Dienste leisten: in der Serienproduktion. Weiterentwicklung nicht ausgeschlossen.

zur Übersicht
© 2017 PersMan. Alle Rechte vorbehalten.