Von Heinz Schelle

© GPM-Magazin PMaktuell - Heft 1/2006, Seite 62. Alle Rechte vorbehalten.
Mehr zum Thema

Barber, R. B.: Understanding internally generated risks in projects.

In: International Journal of Project Management 23, 2005, pp. 584 – 590

Der Autor unterscheidet Projektrisiken, die in der Organisation selbst generiert werden, und extern generierten Risiken. Als interne Risiken werden definiert „those risks, that have their origin within the project organisation or its host, rising from their rules, policies, processes, structures, actions, decisions, behaviours or cultures.“ Ein Beispiel für ein solches Risiko ist die Übertragung der Projektleitung an einen Mitarbeiter, dem die notwendige Erfahrung und die erforderlichen Fähigkeiten dafür fehlen. Die Kernthese der Studie ist, dass das Management dieser internen Risiken in der Regel schlecht ist. In einer empirischen Untersuchung, die allerdings nur neun Projekte umfasste – die Art der Vorhaben wird nicht erwähnt –, wurden Risiken identifiziert und nach ihrer Bedeutung klassifiziert. Dabei wurden vor allem hohe bzw. extrem hohe Risiken herausgestellt. Die These, dass diese Risiken nur eine geringe Aufmerksamkeit beim Management gefunden hatten, wurde bestätigt.

Projektrisiken und Reifegrad: Ein Plädoyer für Reifegradmodelle

Interessant ist daneben aber vor allem die Bestätigung einer zweiten These Barbers, die freilich noch durch eine größere Stichprobe untermauert werden müsste. Sie lautet: Das Ausmaß der intern generierten Risiken korreliert eng invers mit dem Reifegrad, den eine Organisation im Projektmanagement hat. Diese Hypothese wird ja auch explizit von den Entwicklern der CMM-Familie herausgestellt, wenn postuliert wird, dass das Risiko der Verfehlung der Projektziele mit dem Reifegrad abnimmt. Die wichtigste Empfehlung, die der Autor für den Kampf gegen interne Risiken gibt, ist dann auch der Rat, intensives Benchmarking zu betreiben und den Reifegrad des Projektmanagements kontinuierlich zu erhöhen, also ein Plädoyer für Reifegradmodelle.

Williams, T.: Assessing and Moving on From the Dominant Project Management Discourse in the Light of Project Overruns.

In: IEEE Transactions on Engineering Management, Vol.52, No.4, November 2005, pp. 497 – 508

Im Gegensatz zur Bundesrepublik wird klassisches Projektmanagement, wie es etwa im PMBOK dokumentiert ist, in den USA weit weniger hinterfragt. Dieser Artikel, der 117 Literaturstellen zitiert, ist eine gewisse Ausnahme. Ausgangspunkt der Untersuchung ist die unbestreitbare Tatsache, dass trotz immer stärkerer Verbreitung des Führungskonzepts Projektmanagement viele Projekte scheitern. Der Autor fragt, warum das so ist, was an der gegenwärtigen herrschenden Projektmanagementtheorie möglicherweise falsch ist und ob Projektmanager ihre Vorhaben anders führen sollten. Leider hat Williams aber nicht untersucht, ob in den fehlgeschlagenen Projekten wirklich nach den Regeln des klassischen Projektmanagements verfahren wurde. So kann man natürlich immer noch sagen: In den nicht erfolgreichen Projekten wurde eben nicht nach dem Stand des Wissens verfahren. Der Verfasser analysiert dann die Wurzeln der heute weitgehend akzeptierten Projektmanagementpraxis, wie er sie auch in der ICB repräsentiert sieht. Gestützt auf die Methodik der System Dynamics kommt er zu dem Ergebnis, dass Steuerungsaktionen, die im klassischen Projektmanagement empfohlen werden, oft zu einem Circulus viciosus führen. Ein Beispiel dafür sind die Folgen, die Brooks in seinem bekannten „Gesetz“ formuliert: „Adding manpower to a late software project makes it later.“ Mit diesem Resultat kommt Williams in die Nähe des deutschen Psychologen Dörner, der derartige Teufelskreise in seiner „Logik des Mißlingens“ sehr plastisch beschrieben hat.

Von der Planlastigkeit des Handelns

In einem anschließenden großen Kapitel werden dann die theoretischen Implikationen des klassischen Modells untersucht. Die drei wichtigsten Annahmen bzw.Charakteristika, die er herausarbeitet:

  • Es wird unterstellt, dass klassisches Projektmanagement selbst evident ist und die Empfehlungen keiner expliziten Theoriebasis bedürfen.
  • Außerdem ist klassisches oder konventionelles Projektmanagement, wie der Autor es auch nennt, im Wesentlichen ein Management des „project scope“, das von der Annahme ausgeht, dass auch komplexe Gesamtaufgaben bewältigt werden können, wenn man sie nur in kleinere Aufgabenbündel zerlegt. „The very basis of project management thinking has been reductionist through decomposition.“
  • Schließlich ist der Ansatz stark planlastig.

Ein wesentliches Fazit der sehr ausführlichen Analyse ist, „that project behavior is complex, counterintuitive and …that the resulting type of project management methods, can be inappropriate and potentially actually disadvantegeous for projects that are characterized by three aspects: they are structurally complex, uncertain and heavily time limited.“

Neue Konzepte im Projektmanagement sind gefragt

Die Folgerungen, die aus den Untersuchungen für einen der jeweiligen Projektart angepassten Managementstil abgeleitet werden, sind sehr umfangreich, zum Teil noch ein wenig vage und können hier schon aus Platzmangel nicht vollständig wiedergegeben werden. Eine der Empfehlungen geht in Richtung agiles Projektmanagement. Weiter fordert der Autor für die oben charakterisierten Projekte, dass sie nicht vollständig vorausgeplant werden sollten,sondern dass sie sich entwickeln (emerge) sollten. Wer sich über neue Ideen im Projektmanagement informieren will und die impliziten Annahmen seiner derzeitigen Projektmanagementpraxis kritisch hinterfragen will, dem kann dieser Artikel, der allerdings einigermaßen mühsam zu lesen ist, ans Herz gelegt werden.


---> Zum Inhaltsverzeichnis von PMaktuell - Heft 1/2006

GPM-Mitglieder erhalten ein kostenfreies Abonnement von projektMANAGEMENTaktuell.
Informieren Sie sich über die Vorteile der GPM-Mitgliedschaft

Anregungen?
Wenn Sie Anregungen zur Online-Ausgabe von PM aktuell haben oder Fehler entdecken, senden Sie bitte eine Nachricht an
PM-Qualifizierung
auf hohem Niveau

Weitere Info...

↑↑↑     --     Impressum | Sitemap | Login Redaktion     --     ↑↑↑ Kontakt | \

Powered by pmwiki-2.1.26 - Optimiert für Bildschirmauflösungen ab 1024 x 768