Projekte: Von gut und schlecht definierten Problemen

In kaum einem Feld des Managements schien lange Zeit eine so große Einigkeit über die „richtige Vorgehensweise“ zu herrschen wie bei der Durchführung von Projekten.[1] Manager:innen, Organisationsentwickler:innen, IT-Berater:innen sowie Expertenberater:innen stimmten weitgehend überein, wie ein Projekt nach „allen Regeln der Kunst“ abgewickelt werden sollte. Voraussetzung für ein erfolgreiches Projekt sei, so lange Zeit die Annahme, die genaue Bestimmung der Projektziele. Im „Pflichtenheft“ sollten die Ziele so konkret beschrieben werden, dass man sich die angestrebte Zukunft plastisch vorstellen könne und die Aufgaben und Tätigkeiten, die zur Zielerreichung nötig seien, aufgelistet werden könnten.[2] Das Projekt sollte, so lange Zeit der überwiegende Tenor in der dazugehörigen Managementliteratur, immer in „typischen, klar unterscheidbaren Phasen und Schritten“ ablaufen. Zu Beginn eines Projektes müssten Pläne erstellt werden, in denen die Zeitpunkte für Auftaktveran­staltungen, Analyse und Diagnose, Datenfeedback, Projektkonzeption, Präsentationen, Umsetzung und Projektabschluss festgelegt würden.[3] Die Logik des klassischen Projektmanagements ist geprägt gewesen durch „Vorstellungen von geplantem Wandel“.[4]

Aber zunehmend sind Kratzer in den Lack des klassischen Projektmanagements gekommen. Bei Untersuchungen über Softwareprojekte wurde festgestellt, dass Projekte häufig ihren Kostenrahmen um das Doppelte überschritten, ihre Dauer in der Regel fast doppelt so lang war wie geplant und die meisten dieser Vorhaben im Laufe ihrer Geschichte einen Neustart erlebten.[5] Die hehren Ideale des Projektmanagements scheinen sich, nicht zuletzt aufgrund der Vielzahl der mehr oder weniger erfolgreich durchgeführten Projekte, abgenutzt zu haben.

Angesichts dieser Krise gab es die typischen Erklärungsversuche, mit denen versucht wurde, das klassische Projektmanagement zu retten: mangelnde Qualifikation der Beteiligten, widerständige, durch tayloristische Arbeitsstrukturen geprägte Mitarbeiter:innen, die fehlende Einsichtigkeit der mittleren Linienmanager:innen in die Notwendigkeit des Projektes, ungenügende Kooperation zwischen Organisations-, Weiterbildungs- und IT-Abteilungen, die Unfähigkeit der Berater:innen. [6] Es wurde eine Diskrepanz zwischen den logischen, rationalen und schlüssigen Projektmanagementstandards und dem irrationalen, emotionalen Verhalten der Mitarbeiter:innen aufgebaut.

Die Probleme des klassischen Projektmanagements wurden individualisiert, also auf Personen geschoben: „Wenn die Mitarbeiter mitziehen würden …“, „Wenn die Beraterin diesen Aspekt nicht übersehen hätte …“ oder „Wenn das Vorstandsmitglied seine Energie nicht in andere Angelegenheiten gesteckt hätte …“. Diese Personalisierung von Problemen ermöglichte es, die Standards des klassischen Projektmanagements auch trotz negativer Erfahrungen in der alltäglichen Praxis aufrechtzuerhalten: Der Plan war gut, bloß leider waren die Menschen noch nicht weit genug. Aber diese Herangehensweise an die Probleme des Projektmanagements konnte auf die Dauer nicht befriedigen. Es bedurfte einer Differenzierung.

Das klassische, auf einen chronologischen Zyklus von Problembestimmung, Ursachenanalyse, Lösungsgenerierung und Maßnahmenbestimmung basierende Projektmanagement ist für den Typ der gut definierten Probleme geeignet. Von gut definierten Problemen spricht man, wenn eine Herausforderung im Detail beschrieben werden kann, die beteiligten Akteur:innen in der Problemdefinition übereinstimmen und alle notwendigen Informationen beschaffbar sind. Dies ermöglicht eine effektive Vorausprogrammierung der Aufgabenerfüllung über Wenn-dann-Regeln.[7]

Der klarste Fall von Lösungen für gut definierte Probleme sind technische Projekte, die einen Wiederholungscharakter haben und durch Routinen zu regeln sind. Zum Beispiel ist das Verlegen von Stromkabeln durch die lokalen Stadtwerke ein solches Projekt. Wenn ein neuer Anschluss gelegt werden soll, lässt sich das Problem – der Haushalt will einen Stromanschluss haben – genau definieren, die Kosten über die durchschnittlichen Preise für die Verlegung eines Meters Stromkabel mal Anzahl der Meter präzise kalkulieren und der Arbeitsablauf entsprechend den Arbeitsrichtlinien der Stadtwerke klar festlegen.

Das klassische Projektmanagement stößt jedoch bei Projekten, bei denen die Probleme nicht gut definierbar sind, an Grenzen, beispielsweise bei Aufgaben, die kein eindeutiges Ziel haben und bei denen zu „Beginn des Projektes noch gar nicht klar ist, in welche Richtung es gehen soll“.[8] Bei Reorganisations­projekten scheitern die klassischen Projektmanagementtools, weil die Findungsphase nie eindeutig abgeschlossen ist, die Aufgaben meistens kein eindeutiges Ende haben und notwendige Ressourcen nur ungefähr abzuschätzen sind. In vielen Produktentwicklungsprojekten hat man es mit Problemen zu tun, in denen entweder die Ziele relativ klar, aber die Methoden nicht gut definierbar sind, oder in denen umgekehrt die Methoden einigermaßen bekannt, aber die Ziele nicht eindeutig sind.[9]

Die Probleme scheinen in diesen Fällen nicht eindeutig bestimmbar zu sein, sie sind schlecht definiert. Unter einem schlecht definierten Problem versteht man ein Problem, über dessen Struktur man nur begrenzte Informationen hat, dessen Definition von Akteur zu Akteur unterschiedlich ist und zu dessen Lösung aufgrund der Komplexität nicht alle Handlungsalternativen erwogen sowie auf ihre Folgen abgeklopft werden können.

Mit solchen schlecht definierten Problemen müssen sich besonders komplexe Organisationsreformen auseinandersetzen. Die Schwierigkeiten, auf denen Reorganisationsprojekte beispielsweise aufsetzen, werden im Verlauf der Zeit häufig umdefiniert: Ging es anfangs noch um Kosteneinsparung, verlagert sich das Ziel mehr zu einer strategischen Neuausrichtung. Managerinnen, die das Projekt anfangs betrieben haben, ziehen sich zurück, andere Akteure kommen hinzu. Auch komplexe EDV-Projekte setzen häufig auf solch schlecht definierten Problemen auf. Die Software, die am Ende eines Projektes herauskommt, hat häufig wenig mit den im Pflichtenheft festgelegten Zielsetzungen und Vorgehensweisen zu tun. Insbesondere die Softwaretechnologie entwickelt ein so starkes „Eigenleben“, dass man eher auf der Grundlage der bereits vorhandenen Tools schließt, was am Ende herauskommt, als dass man für sauber definierte Ziele die entsprechenden Tools heranzieht.

Wie wirkte sich die klassische lineare Vorgehensweise bei Projekten mit schlecht definierten Problemen aus? In den Projekten wurde festgestellt, dass es immer wieder Planabweichungen in Form von Zeit-, Budget- oder Personalkapazitäts­überschreitungen gab. Je undurchsichtiger das Problem, mit dem sich ein Projekt auseinandersetzte, desto häufiger musste in einem logisch-linearen Planungsprozess also zurückgesprungen werden, um die Zielerreichung zu modifizieren. Im Projektablauf entstanden sogenannte „Echternacher Springprozessionen“, in denen es zwei Schritte vorwärts und einen zurückging.[10] Der Projektverlauf war nicht eine stetige Fortentwicklung, in der ein Entwicklungstand eine feste verbindliche Basis für den nächsten Schritt darstellte. Vielmehr bildete sich ein Rückkopplungskreis aus, in dem immer wieder zurückgesprungen werden musste, um Planungen anzupassen. Durch diese Rücksprünge konnte sich ein Projekt zwar immer mehr der Realisierung annähern, aber die Planungssystematik verlor an Linearität. Die Komplexität wuchs sehr stark an.

Der in Mode gekommene agile Projektansatz macht letztlich nichts anderes, als diese in der Praxis zu findenden Rücksprünge in die offizielle Planungs­philosophie für Projekte zu integrieren. Die Idee eines solchen agilen Projektmanagements ist es, den Projektprozess kontingent zu halten. Kontingenz bezeichnet die Offenheit einer Situation: „Es geht so, aber auch anders, allerdings nicht beliebig.“ Der Grundgedanke der Kontingenz ist, dass es bei schlecht definierten Problemen keinen „one best way“ gibt, sondern verschiedene Wege existieren, um voranzukommen. Welche eingeschlagen werden, hängt von der Situation, den Entwicklungen der Organisation, den Machtkonstellationen oder zufälligen Veränderungen in der Umwelt ab.

[1] Der Beitrag basiert auf einem Text, den ich zusammen mit Wolfgang Schnelle geschrieben habe. Siehe Stefan Kühl, Wolfgang Schnelle: Wenn klassisches Projektmanagement in die Sackgasse führt. In: Birgit Ehrl-Gruber (Hrsg.): Handbuch Innovatives Projektmanagement. Kissing 2006, S. 1–24.

[2] So zum Beispiel Pitter A. Steinbuch: Projektorganisation und Projektmanagement. Ludwigshafen 1998, 28ff.

[3] So zum Beispiel noch Klaus Doppler, Christoph Lauterburg: Change Management. Den Unternehmenswandel gestalten. Frankfurt a.M., New York 1994, 101 und 285.

[4] John R. Kimberly: Reframing the Problem of Organizational Change. In: Robert E. Quinn, Kim S. Cameron (Hrsg.): Paradox and Transformation. Toward a Theory of Change in Organization and Management. Cambridge 1988, S. 163–168, hier S. 165.

[5] Siehe früh John H. Lehmann: How Software Projects are Really Managed. In: Datamation 25 (1979), 1, S. 115–129, hier S. 115. Für eine lesenswerte frühe Kritik siehe Adrian W. Fröhlich: Mythos Projekt. Projekte gehören abgeschafft. Bonn 2002, 25ff.

[6] Siehe nur beispielhaft für solche Erklärungen Georg Kraus, Reinhold Westermann: Projektmanagement mit System. Wiesbaden 1997, 195ff.

[7] Maßgeblich Herbert A. Simon: The Structre of Ill Structured Problems. In: Artifical Intelligence 4 (1973), S. 181–201. Leichter zugänglich als Argument in James G. March, Herbert A. Simon: Organisation und Individuum. Menschliches Verhalten in Organisationen. Wiesbaden 1976, 150ff.

[8] So G. Kraus, R. Westermann: Projektmanagement mit System (wie Anm. 295), 187f.

[9] Siehe zu Projekten aufschlussreich und umfassend Marcel Schütz, Pia Lehmkuhl, Heinke Röbken, Etienne Witte: Projektmanagement. Eine Einführung aus sozial- und organisationswissenschaftlicher Sicht. Wiesbaden 2022.

[10] So Rolf G. Ortmann: Projektmanagement in der Softwareentwicklung: Definierte Abläufe oder offene Prozesse. In: Vdf (Hrsg.): Management von Großprojekten. Zürich 1993, S. 1–10, hier S. 2.