Kritik am klassischen Projektmanagement

Das klassische Projektmanagement, wie es von [Gareis, 2006], [Patzak & Rattay, 2004], PMI, IPMA, sowie speziell für IT Projekte von [Jenny, 2001] beschrieben wird, erfährt oft Kritik, dass es zu schwergewichtig und „over-engineered“ sei. Speziell bei IT-Projekten wird in der Praxis der unverhältnismäßig große Planungs-, Dokumentations- und Kommunikations-Overhead bemängelt, der Projekte in ihrem Fortschritt lähmt. In einer Welt die von rasantem technischem Fortschritt, dynamischen Märkten, unsteten wirtschaftlichen Rahmenbedingungen sowie sich stetig ändernden Kundenanforderungen wird die Forderung nach einem Werkzeugen lauter, die einen effizienten und flexiblen Ansatz zum Managen von Projekten bieten. 
 
Ist das klassische Projektmanagement wirklich so schwergewichtig, ist der Overhead tatsächlich so groß? Wir wollen ein paar einfache, praktische Überlegungen dazu anstellen, vor allem die Frage: wie viel Planung, Dokumentation und Kommunikation ist beim klassischen Projektmanagement notwendig oder vorgesehen? Die jeweils kleinste Ausprägung dieser drei Aspekte auf Projektmanagement-Ebene nennen wir wie unter Projektplanung beschrieben PM-Artefakte. 
 
Natürlich ist es schwierig, die Zeit zu messen, die das Erstellen oder Pflegen eines jeden PM-Artefaktes benötigt. Das ist sehr abhängig vom Projekt selbst, und auch von der Art des PM-Artefaktes – ein Produktstrukturplan ist nicht in gleichem Maße aufwändig zu erstellen wie ein Einsatzmittelplan oder Terminplan. Lassen wir also den genauen Aufwand pro PM-Artefakt außer acht, setzen wir ihn als jeweils konstant voraus und widmen uns stattdessen der Frage: mit wie vielen PM-Artefakten haben wir es im klassischen Projektmanagement zu tun? 
 
Beim vorgestellten Ansatz für IT Projektmanagement mit seinen neun Planungselementen gemäß [Jenny, 2001] sind das erstaunlich viele, wenn man sich einfacher Arithmetik bedient. Bei einem Projekt ohne Gesamtprojektplan lautet die einfache Formel für die Gesamtanzahl an PM-Artefakten (abgekürzt PM-A): 
 
Gesamt-Anzahl PM-A = (Anzahl PM-A Projektplan) + {(Anzahl Phasen) x (Anzahl PM-A Phasenpläne)}
 
Betrachten wir ein nach Definition von [Jenny, 2001] mittelgroßes oder „normales“ Projekt ohne Gesamtprojektplan auf Basis des konstruktivistischen 5-Phasen-Modells, so besteht dies aus einem Projektplan, welcher 5 Phasen vorsieht und diese mithilfe von 9 Planungselementen bestehend aus insgesamt 13 PM-Artefakten abbildet. Jede Phase wird ihrerseits wieder in 9 Planungselementen mit ihren 13 PM-Artefakten abgebildet. In unserer Formel bedeutet das: 
 
Gesamtanzahl PM-A = 13 + (5 x 13) = 78
 
Das bedeutet, wir haben es mit 78 Textdokumenten und Listen zu tun, und haben dabei noch Planungsaspekte wie Leitbild, Organisationshandbuch, Projekthandbuch, Machbarkeitsstudie, Projektantrag, Projektauftrag und Produktstrukturplan nicht berücksichtigt. Auch Teilaspekte des institutionellen Projektmanagements haben wir außer Betracht gelassen, alleine die Abwicklungs-Dokumentation besteht noch aus etwa 10 zusätzlichen Dokumenten, die Systemdokumentation aus 21 weiteren, das Projekt-Berichtswesen sieht zahllose Berichts-Dokumente vor - um nur einige Beispiele zu nennen. Diese Dokumente wollen alle erstellt und gepflegt werden. Für sehr große, umfangreiche Projekte mag das angemessen sein, jedoch erscheint die Frage berechtigt, ob das die richtige Herangehensweise für kleinere bis mittelgroße Projekte ist. Eine Antwort darauf liefern die vergleichsweise jungen Agilen Methoden
Letzte Änderung: 03.11.2010, 14:01 | 433 Worte