Die neue Rolle der Planung im Projektmanagement – Teil 1

In letzter Zeit kommt die Planung als wichtigster Stützpfeiler des traditionellen Projektmanagements zunehmend unter Druck. Vor allem die Befürworter des „Agilen (Projekt-)Managements“ zweifeln die Tauglichkeit der bisherigen Planungsansätze in einer dynamischen Umwelt an und fordern ein Umdenken. In dieser Beitragsreihe im GPM BLOG soll der Frage nachgegangen werden, wo das herkömmliche Verständnis von Planung an seine Grenzen stößt, welche Rolle der Planung dann zukünftig im Projektmanagement zukommt und wie Planung dann konkret aussehen kann.

1.) Definition und Abgrenzung des Planungsbegriffs
Planung wird oft definiert als gedankliche Vorwegnahme von Handlungsschritten, die zur Erreichung eines Zieles notwendig erscheinen (siehe auch bei Wikipedia: „Planung„).

Der Zeitpunkt des Planens liegt also vor der Zielerreichung, Planung ist demnach auf die Zukunft gerichtet und damit einer mehr oder weniger großen Unsicherheit unterworfen. Planung fußt auf den Informationen, die zum Zeitpunkt des Planens verfügbar sind. Dies können beispielsweise Informationen zu Ausgangs- oder Rahmenbedingungen, zu Entwicklungsverläufen, zu Wechselwirkungen oder zu Störfaktoren sein. All diese Prämissen schränken die Handlungsoptionen für die Planung ein, sie haben wesentlichen Einfluss auf die Planung und das Planungsergebnis.

Planung ist gemäß dieser Definition ein rein gedanklicher Akt und damit abgetrennt von der Ausführung. Bei diesem Verständnis von Planung dominiert „Kopfarbeit“ die „Ausführung“. In herkömmlichen Organisationen manifestiert sich diese Trennung oft auch in unterschiedlichen Aufgabenbereichen: Eine Abteilung plant, andere führen den Plan dann aus. Das Ergebnis der Planung sind Pläne, entweder auf Papier oder als elektronische Datei. Allerdings können Pläne auch im Kopf von Menschen existieren, was dann eine Kommunikation („Explikation“) auf die eine oder andere Weise notwendig macht.

Wozu werden Pläne erstellt bzw. welche Funktionen erfüllt die Planung? Hier geben Stefan Strohschneider und Rüdiger von der Weth in „Ja, mach nur einen Plan„, Bern, Verlag Hans Huber, 1993, S. 12 interessante Einblicke:

  • Pläne dienen im Allgemeinen zur Festlegung der zeitlichen Abfolge und der Orte von Handlungen. Sie geben Antworten auf die sogenannten „W“-Fragen, also was geschehen soll, wann und wie es geschehen soll, womit usw.
  • Pläne sind kommunizierbar, sie machen anderen Menschen die Absichten des Planers und seine Vorgehensweise deutlich.
  • Pläne ermöglichen daher die Koordination der Aktivitäten mehrerer Personen, insoweit sich diese auf ein gemeinsames Ziel beziehen.
  • Pläne verpflichten. Sie ermöglichen eigene Planungen im Vertrauen darauf, dass andere ihre Pläne einhalten, sie ermöglichen es anderen Menschen, mit den Resultaten unserer geplanten Aktivitäten zu rechnen. Pläne schaffen damit intersubjektive Handlungssicherheit.
  • Pläne machen Ziele und Vorgehensweise transparent und diskutierbar, sie ermöglichen eine Verbesserung von Handlungsmustern, die Redefinition von Zielen.
  • Pläne entlasten: Hat man einmal geplant, muss man nicht alle Details ständig im Gedächtnis haben und immer wieder neu durchdenken.
  • Pläne bringen das aktuelle Handeln mit übergeordneten Zielen in Beziehung, indem sie die gegenwärtige Aktivität in einen größeren Zusammenhang (zur Erreichung eines bedeutenden Ziels) einordnen.
  • Pläne reduzieren Unsicherheit. Ein Plan auf dessen Realisierbarkeit wir vertrauen, strukturiert unbekanntes Terrain, setzt Ordnungsmarken, verschafft uns das Gefühl von Kompetenz, was sich angesichts komplex-dynamischer Planungsfelder häufig als ganz entscheidender Antrieb zum Planen erweist.

Pläne ermöglichen überdies die Analyse und Bewertung von Entscheidungsvarianten, sie dienen während der Realisierung zum Vergleich mit der tatsächlichen Situation und damit als Grundlage für Entscheidungen für Steuerungsmaßnahmen. Nach der Zielerreichung kann anhand der Pläne nachvollzogen werden, inwieweit die Planung mit der Realität übereingestimmt hat, oder bei zukünftiger Planung andere Prämissen zugrunde gelegt werden müssen. Pläne dienen der Dokumentation und damit der Nachvollziehbarkeit von Handlungen, sie können z.B. Vertragsbestandteil sein und bei Rechtsstreitigkeiten zwischen Partnern als Beweismittel herangezogen werden.

Die Planung selbst erfordert Zeit und bindet Ressourcen. Das Mehr an Aufwand in der Planungsphase wird oft in Kauf genommen, um dann bei der Realisierung Aufwand zu sparen. Planung setzt bestimmte Kompetenzen voraus, um das gewünschte Ergebnis effektiv und effizient zu erreichen. Vorgehensmodelle, Planungsmethoden und -tools sollen die Planenden bei der Planung unterstützen.


Ähnliche Beiträge im GPM BLOG:

Schlagwörter: , , , ,

Kommentare

  1. avatar Roland Spengler

    Ich finde es nicht zielführend wenn immer die Diskussion agil vs. klassisch zu solchen Themen führt. Wenn man die Methodik von Scrum z.B. verinnerlicht, dann fällt doch auf, dass:

    1. Das Product Backlog und das Sprint Backlog ganz klare deutliche Planungsinstrumente sind.
    2. Das Team im sprint planning meeting den Sprint plant.
    3. Das task board nichts anderes als eine Aktivitätenplanung darstellt
    4. die Planung kleinräumig auf Tagesaktivitäten heruntergebrochen wird

    Summa summarum wird dann in einem agilen Projekt vom Team derart kleinräumig geplant, dass man von atomisierter Planung reden kann. Die Kritik an der klassischen Methodik kann dann also nur sein, dass sie zu grob plant und zu viele Freiheiten lässt. :-)

    Die Wirklichkeit ist doch selten so, dass jemand eine Idee hat und mit einem Team von idealistischen 7 Leuten schon mal agil anfängt zu entwickeln und am Ende kommt ein super Produkt heraus. Die 7 müssen dafür auch kein Geld bekommen und Nahrung und Dach über den Kopf brauchen sie auch nicht.
    In der Regel muss der finanzielle Aufwand abgeschätzt und ein Business Plan erstellt werden, sonst bekommt man kein Geld dafür (weder von einer Bank, noch von einer Firmenleitung). Dann muss man sich zusammensetzen und ein Backlog erstellen (das ist nichts anderes als klassische Anforderungsanalyse), dann wird ausgewählt was in 4-6 Wochen umsetzbar ist und auf Tagesaktivitäten heruntergebrochen (das ist dann Grobplanung des Ganzen und Feinplanung für eine erste Projektstufe). Ich verstehe bis heute nicht wo der Unterschied zwischen klassisch und agil festgemacht wird, um die Instrumente zu kritisieren, da der Unterschied vor allem in der Teamkultur liegt und nicht in der Planungsmethodik, oder?

    Grüße Roland

    1. Herr Spengler, da stimme ich Ihnen vollkommen zu, deshalb habe ich die Artikelserie ja aufgemacht, um zu zeigen, dass sich die Planung als zentrales Element des Projektmanagements insgesamt weiterentwickelt. Diese Konfrontation zwischen „klassisch“ und „agil“ passt nämlich überhaupt nicht, ich kenne kaum einen PM, der rein „klassisch“ arbeitet und keinen, der rein „agil“ arbeitet. Die entscheidende Frage für EHER klassisch oder EHER agil ist doch, welche Anforderungen ich habe, und dann bediene ich mich eben aus dem Methodenkoffer.

      1. avatar Roland Spengler

        Herr Wagner, da reden sie mir aus der Seele. Ich habe gerade in im Blog von 23actions dazu etwas geschrieben, das dann Roland Dürre dort wunderbar zusammengefasst hat.
        Die wichtigen Tugenden der Zukunft sind gemeinsame Umfeldbeobachtung und Kollaboration.

        Da ich nicht nur IT betrachte, verstehe ich die Diskussion klassisch versus agil sowieso nicht. Sie betrifft nur die IT-Projektleiter, da offensichtlich in der IT 60 Jahre später nun auch die Prozessorientierung dazu geführt hat Lean Management zu betrachten und für sich zu adaptieren.
        Spannend finde ich, wenn die Vordenker sogar die Begriffe des Prozessmanagements aus dem Toyota Prozesshaus übernehmen und ich dann Diskussionen über Kanban mit IT’lern führe, bei denen ich feststelle, dass die Kollegen noch nicht einmal wussten, dass auch der Name aus dem Toyota-Prozesshaus entstammt und nicht nur die Methodik …

        Ich sehe das Problem, dass Prozessmanager und Projektmanager offensichtlich in vielen Firmen unterschiedliche Karrierepfade darstellen und deswegen viele Projektleiter keine Prozess-Profis sind. Als Berater mit Umstrukturierungserfahrung und Prozessberatungserfahrung ist man dann verblüfft, dass in der IT die Anhänger der agilen Bewegung oftmals keinerlei Grundwissen über Taylorismus versus Lean Management haben und das obwohl viele oft sogar ITIL kennen.

        Ich bin auch felsenfest davon überzeugt, dass bei Firmen die immer wieder eine ähnliche Art von Projekten durchführen die klassischen, selbstentwickelten internen Vorgehensmodelle jeglicher rein agiler Durchführungsstrategie überlegen sind. Ich denke da z.B. an Firmen, die Kraftwerke herstellen, oder Fertigungsstrassen, oder Bauträger.
        Dort sind dann die Projekte wegen ihrer Charakteristika zwar einmalig und auch entsprechend komplex, aber das Prozesshaus für die Projekte ist immer gleich.

        1. Ich komme aus der Automobilentwicklung und habe mal selbst eine kurze Ausbildung bei Toyota gemacht, Was da immer vergessen wird: KanBan & Co. sind Methoden, die aus der schieren Not entstanden sind, Toyota kämpfte nach dem Krieg ums Überleben, die japanische Kultur ist Kultur ist auf Risikovermeidung ausgelegt, Disziplin sowie Gehorsam sind wichtige Tugenden und Abweichungen vom Standard werden nicht toleriert bzw. sogar bestraft. Toyota hat vor ein paar Jahren einen Strategieschwenk hin zu mehr radikalen Innovationen versucht und ist damit praktisch gescheitert, die Kultur war auf Kaizen, d.h. die inkrementelle Verbesserung geimpft, radikale Verbesserungen oder Innovationen setzen aber ein ganz anderes Denken voraus (z.B. wollte Toyota Kostenoptimierung nicht mehr auf Teileebene, sondern über das Gesamtsystem erzielen, die gesamte Denke war aber auf Teile reduziert worden…). Ich sehe also durchaus auch Gefahren durch das „Lean Thinking“ bzw. die Anwendung im Rahmen des Agilen PM…

          1. avatar Roland Spengler

            Klar, deswegen sollte man auch die Methodik und die Historie, woher sie stammen kennen. Nur wer ein gesundes und gutes Fundament hat ist in der Lage ein Projekt der Situation angemessen zu steuern.

            Aus diesem Grund sind mir Moden und Hype-Cycle nicht geheuer.

            Mir ist es auch ungeheuerlich, wenn ich mit agilen Entwicklern rede und dann die Auswahl des Projektpersonals knallhart durchgezogen wird. Es geht in diesen Diskussionen nicht darum mit dem vorhandenen Personal ein Projekt zu schaffen, es geht immer darum agile Experten in einem Team zusammen zu bringen. Da wird dann auch schnell mal in der Diskussion gesagt, dass ein Mitarbeiter, der nicht agil arbeiten kann eben die Firma verlassen muss …
            Wenn ich also die Erfolge vergleiche komme ich schnell dazu ein klassisches Projekt mit durchschnittlichen Mitarbeitern mit einem agilen Team aus sehr, sehr guten Entwicklern zu vergleichen. Aber was hat dann den Erfolg ausgemacht? Die agile Vorgehensweise oder der Qualifikationsvorsprung des Teams.

            Ich habe auch schon mehrere agile Katastrophen beobachtet, wo die Teams mental nicht in der Lage waren agil zu arbeiten und das Projekt dann voll an die Wand gelaufen ist.

            Vernetzte virtuelle Teams zu führen ist jedoch auch nicht einfach, da man nur schwer die Einflussfaktoren erkennt, die behindern oder fördern. Auch die Motivationsmethodik hat hier so ihre Eigenarten. Bei uns ist es auch so, dass dann oft immer die gleichen Mitarbeiter mit „Heldensyndrom“ an allem partzipieren und das Ganze vorantreiben, während die größere Masse sich hinter ihnen versteckt. In diesem Sinne ist dann die „Mitmach-Firma“ für uns als Führungskräfte und auch für jeden Mitarbeiter sehr anstrengend.

  2. avatar Manfred Damsch

    Agil heißt nicht unbedingt Scrum und nur Softwareentwicklung. Product Backlog, Sprintbacklog und Sprints sind allesamt für die Softwareentwicklung in großen IT-Vorhaben erdacht worden. Sie beziehen sich nicht auf integrierte Systeme in denen es nur einen einzigen Zielpunkt (das Gesamtprodukt ist fertig) gibt und wo es dementsprechend auf eine genaue zeitliche Synchronisation ankommt.

    Für Konsumer Elektronik Produkte gilt z.B.: Auch wenn es manchmal den Eindruck macht, werden doch die allermeisten Produkte komplett fertiggestellt, bevor sie dem Markt angeboten werden. Einzig die eingebettete Software wird heutzutage erst nach Verkaufsstart noch verändert, dies ist durch die mittlerweile üblichen nachträglichen Upgrades möglich, sinnvoll und auch vom Kunden gewollt – wichtig ist die perfekte Funktion des HW-Systems bei Verkaufsstart.

    Agil bedeutet im Umfeld von zeitkritischen Komplettsystemen in der Tat vor allem eine Veränderung der Denkkultur und des Kommunikationsverhaltens. Das „Agile Manifest“ mit seinen 4 Grundwerten

    1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
    2. Funktionierende Software ist wichtiger als umfassende Dokumentation
    3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung
    4. Die Offenheit für Veränderung ist wichtiger als das Befolgen eines Plans

    zielen genau darauf ab und lassen sich in diesem Umfeld natürlich nur bedingt einhalten. Über eine Aufweichung des extrem formalen Ansatzes des klassischen Projektmanagements lässt sich das Projektmanagement aber auch in Bereiche einführen, die sich im Grunde ihres Wesens eher von strukturierten Methoden distanzieren. Das ist nicht nur in der Softwareentwicklung der Fall, sondern auch in allen anderen, primär kreativ arbeitenden Umfeldern der Fall. Der Versuch, mit formalen Standards des Projektmanagements im Bereich der Business Development, Marketing und Produktdefinition Fuß zu fassen, wird immer auf Ablehnung stoßen. Die für die planungsintensiven, klassischen Methoden erforderlichen Ziele werden ja erst im Laufe des Vorhabens herausgearbeitet.

    Im Grunde wird natürlich in allen Projekten nur so weit detailliert geplant, wie es in der gegenwärtigen Situation möglich und sinnvoll ist. Der Unterschied besteht aber in der Grunderwartung aller Beteiligten im Prozess. Mit dem agilen Ansatz lässt sich bei eben diesen Grunderwartungen Projektmanagement sanft und auf die reale Situation angepasst, auch in kreativen Bereichen einführen. Damit ist dann auch den primär strukturiert, zielorientiert denkenden Umsetzern geholfen.

    Übrigens lässt sich feststellen, dass es Projektmanagement schon so lange gibt, wie Menschen irgendwelche Vorhaben umsetzen. Nicht erst seit der „Erfindung“ des Projektmanagements irgendwann im 20 JH. Es gibt viele Menschen, die mit dem Begriff Projektmanagement auch heute noch nichts anfangen können und wollen. Die von Ihnen koordinierten Vorhaben (nennen wir sie einfach mal nicht Projekte) werden wohl eher intuitiv und damit agil gemanaged.

    Ich persönlich sehe in agilen Ansätzen vornehmlich den Versuch, die gelebte Realität zu beschreiben und zu legitimieren und damit dem Projektmanagement den Schrecken zu nehmen. Aus eigener Erfahrung weiß ich, dass sich viele Menschen vor dem Projektmanagement in seiner extrem formalen Ausführung „fürchten“ und/oder dieses von Grund auf ablehnen. Wer kreative Menschen mit Detailplänen und Actionlisten konfrontiert und zur Anwendung dieser zwingen will, muss sich über deren Abwehrhaltung nicht wundern. Die bedingungslose Umsetzung von zuvor – möglichst noch von anderen Menschen – erstellten Plänen erstickt die eigene Kreativität und macht das Individuum zum Instrument. Das hat auch schon in den extremen Ansätzen der Industrialisierung (Taylorismus) entsprechende Gegenwehr provoziert… Heute sind wir in vielen Bereichen schlauer und fördern die Kreativität des Teams – Teamleistung >> Summe aller Einzelleistungen.

    Abschließend möchte ich trotzdem feststellen, dass der klassische Ansatz immer noch die strukturierteste und damit berechenbarste Form des PM ist. Damit hat dieser Ansatz seine Berechtigung für alle Vorhaben mit klarer Zielorientierung.

    Irgendwann im Laufe der Reifung wird wohl jedes Vorhaben mal diesen Modus erreicht haben und es kommt zu einem fließenden Übergang…

  3. avatar Alfred Oswald

    Meines Erachtens bringt die oben angegebene Definition „Planung wird oft definiert als gedankliche Vorwegnahme von Handlungsschritten, die zur Erreichung eines Zieles notwendig erscheinen.“ den wesentlichsten Aspekt des Themas Planung zum Ausdruck: Planung ist eine nachvollziehbare Auseinandersetzen mit der Zukunft. Als solche dient Planung dazu, sich auf die Zukunft vorzubereiten. Hierbei liegt der Fokus darin, die eigene Aufmerksamkeit und die Aufmerksamkeit anderer Teammitglieder oder Stakeholder im Sinne der Zielerreichung zu trainieren. In Abhängigkeit der Erfahrung und der Persönlichkeit des Planenden oder desjenigen der den Plan umsetzen soll, kann der Plan aber auch zu einem Mittel der rigiden Direktion verkommen. Ich habe die Erfahrung gemacht, dass ein Plan, auch in einem kreativen Umfeld, wie bei Forschern oder auch Softwareentwicklern, sehr geschätzt wird. Und zwar wird er dann geschätzt, wenn er als Mittel der Zukunftsexploration eingesetzt wird und nicht als Mittel nach dem sich die Zukunft zu richten hat. Damit hat Planung sehr viel mit Führung zu tun; innovative Projekte benötigen einen viel offeneren Führungsstil und damit Planungsstil als Projekte, die in einem bekannten, stabilen Kontext angesiedelt sind. So gesehen sind die Prinzipien des agilen Manifestes für mich „Eisbrecher“, mit denen die rigide Planungskultur der Vergangenheit in Frage gestellt und aufgebrochen wurde. Es ist meines Erachtens umso tragischer, dass die agile Vorgehensweise heute sehr oft zum allein selig machenden Heilsversprechen geworden ist, wohingegen sie ehemals für mehr Offenheit und Menschlichkeit angetreten ist.

    1. Richtig, Planung hat immer was mit Führung zu tun, und das Führungsverständnis hat sich in den letzten Jahren ziemlich verändert. Insbesondere der Stil der Führung und die Integration der Mitarbeiter als Experten. Die Situation im Projekt in ihrer Gesamtheit erfordert ein angepasstes Führungsverhalten, da bringen uns auch die Vokabeln „agil“ und „klassisch“ nicht weiter, weil sie Punkte auf einer sehr breiten Skala der Möglichkeiten sind. Der Projektleiter muss vielmehr virtuos aus einem Repertoir an Möglichkeiten wählen, um Erfolg zu haben…

  4. avatar Roland Spengler

    @Herr Oswald: mit ihrem Schlussabsatz treffen Sie den Nagel auf den Punkt. Die agilen Methoden wollten einen Kulturwandel und funktionieren auch nur, wenn dieser Kulturwandel in der Organisation vollzogen wird. Hierzu gibt es einen wunderbaren Artikel, der auch diskutiert, dass die agilen Methoden sich nicht für jede Kultur eignen:

    http://www.methodsandtools.com/archive/agileculture.php

    Problematisch wird es immer dann, wenn man die Methodik zum Dogma erhebt und nicht situationsbezogen anwendet. Ich stimme also immer zu, wenn für ein sowohl als auch plädiert wird. Das bedeutet aber auch, dass der professionelle Projektleiter sowohl die klassischen, als auch die agilen Methoden kennt und beherrscht. Dogmatische Diskussionen habe ich immer nur mit Projektleitern, die nicht beides kennen.

    Wobei ich immer nicht verstehe, woher der Ansatz stammt die Planung als Direktion zu verstehen. Ich habe noch nie Projekte erlebt, in denen die Planung etwas anderes war als „Mittel zur Zukunftsexploration“.

  5. avatar Max L. J. Wolf

    Was will ich denn mit der Planung? Planung ist mehr als „Mittel zur Zukunftsexploration“. Wie beim Flugsimulator will die Projektleitung und alle Beteiligten wissen, ob die Planung, wie gedacht, durchführbar ist. Planung kann auch als Leitsystem bei einem Flughafen gesehen werden, an dem sich die Autopiloten der Flugzeuge orientieren. Die einmal verabschiedete Planung ist auch kein Dogma. Bei den Meilensteinen soll auch geschaut werden, ob die kommenden, geplanten Abschnitte (Arbeitspakete) noch passen. Sollte dies nicht der Fall sein, ist die Planung den neuen Gegebenheiten anzupassen. Planung prüft die organisatorische Machbarkeit des Vorhabens und gibt den Beteiligten Orientierung, wohin die Reise gehen soll.

    1. Planung ist kein Dogma – das ist für mich der Schlüsselsatz! Das wird ja immer von den Agilisten behauptet, in der Praxis sind die Projektmanager ja recht pragmatisch, deswegen möchte ich in der Artikelserie ja auch die (neue) Rolle der Planung herausarbeiten, Max L.J. Wolf hat wichtige Aspekte herausgestellt, hier gilt es anzuknüpfen…

Leave a Reply

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert. *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>