Wenn es darum geht, Projekte in Unternehmen erfolgreicher durchzuführen, versucht man dies vor allem auf zwei Wegen zu erreichen: Zum einen sollen die Kompetenzen der Beteiligten in der Methodik oder bei den Softskills – dazu gehört auch die Teamentwicklung – erhöht werden. Zum anderen möchte das Unternehmen die Projektmanagement-Methodik an sich verbessern, in dem es Multiprojektmanagement, Software, Checklisten oder Handbücher etc. einführt bzw. optimiert und ein Project Management Office einrichtet.

Zweifellos sind all diese Elemente wichtig. Und als notwendige Elemente eines erfolgreichen Projektmanagement-Systems sind sie auch unbedingt im Zusammenhang zu sehen; denn wenn eines dieser Elemente isoliert betrachtet und betont wird, fangen die Probleme in der Projektarbeit meist schon an. Darauf haben nicht zuletzt auch Beiträge im Projekt Magazin aufmerksam gemacht: So thematisierte z.B. Klaus D. Tumuscheit, dass PM-Zertifizierungen häufig als Ersatz für verbindliche Projektmanagement-Strukturen und ‑Prozesse gesehen werden (Tumuscheit, Projekt Magazin 08/2010), während Dr. Georg Angermeier Sozialkompetenz als Lückenbüßer beschrieb für fehlende Methodenkompetenz, unklare Projektorganisation und schlecht definierte Projektziele (Angermeier, Projekt Magazin 23/2010).

Ich möchte die Diskussion noch um einen weiteren Aspekt bereichern, der meiner Erfahrung nach bisher zu wenig beleuchtet wurde. Um die Qualität des Projektmanagements in Unternehmen zu steigern, setzen Geschäftsführer und Vorstände vor allem auf die individuellen Kompetenzen und/oder auf die Verbesserung der Methoden und Tools. Aber das gesamte Unternehmen als komplexes soziales System mit Strukturen, Prozessen, Regeln und Kultur taucht als Ansatzpunkt für die Verbesserung des Projektmanagements nur selten auf. In diesem Beitrag möchte ich deshalb an konkreten Beispielen aus meiner Erfahrung aufzeigen, dass ein expliziter Blick auf das vollständige soziale System einer Organisation bei der Einführung von Projektmanagement bzw. dessen Optimierung unerlässlich ist.

Typische Probleme aus der Praxis

Als externe Organisationsberater haben wir einige Industrieunternehmen ganz unterschiedlicher Branchen und Größe dabei unterstützt, deren Projektmanagement zu verbessern. Projektmanagement war dabei immer als ein Tool zur Steuerung des Wertschöpfungsprozesses "Produktentwicklung" gedacht. Es handelte sich also immer um Entwicklungsprojekte, oft im Kundenauftrag. Immer ging es in diesen Unternehmen darum, eine festgefahrene Situation in der übergreifenden Projektarbeit zu überwinden, die von Konflikten und großen Reibungsverlusten gekennzeichnet war. Es stand nicht ein einzelnes Projekt im Fokus, sondern generell die ganze Zusammenarbeit in den Entwicklungsprojekten.

Die Unternehmen hatten immer bereits einiges getan, um Projektarbeit als Managementmethode im Unternehmen zu etablieren: Die verantwortlichen Mitarbeiter waren mit der Projektmanagement-Methodik vertraut, es gab Prozess- und Rollenbeschreibungen, Projektmanagement-Handbücher, ein Tool für Projektmanagement und jemand, der sich um das Projektmanagement kümmerte (als Projektassistenz, Project Office etc.).

"Was brauchen die denn noch?"

Unser erster Blick auf alles, was bereits vorhanden war, um die Projektarbeit erfolgreich zu gestalten, ließ uns meistens staunen: "Die haben doch schon alles, was sie für gutes Projektmanagement brauchen! Was fehlt denn noch?" Damit hatten wir schon eine gute Arbeitsfrage gefunden für unseren ersten Schritt, nämlich Interviews mit den involvierten Mitarbeitern und dem Management. Dabei konnten wir meist folgende Probleme feststellen:

Unklare Rollen

Fast immer war die Rolle der Projektleiters (oder des Projektmanagers) alles andere als klar. Soll der leiten, managen oder nur koordinieren? Führt der? Wenn ja – wie viel Einflussmöglichkeiten bekommt er und welche Befugnisse genau? Wenn wir die beteiligten Akteure in den Projekten fragten, wie z.B. Mitglieder der Projektteams, Linienmanager, Geschäftsführer und die Projektleiter selbst, hatte jeder eine andere Antwort. Und natürlich hatten die Linienmanager meist die Vorstellung, dass ein Projektleiter eher koordiniert als führt. Als Folge dieses uneinheitlichen Verständnisses der Projektleiter-Rolle ließ sich beobachten, dass es immer wieder zu falschen Erwartungen und zu Missverständnissen in der Projektbearbeitung kam, die vor allem die Projektleiter viel Zeit und Kraft kosteten.

Kein einheitliches Verständnis von Aufgaben und Befugnissen

Ähnliches ließ sich auch bei den anderen Projektakteuren beobachten: Das Verständnis ihrer Aufgaben und Befugnisse war alles andere als einheitlich. Bei den Projektteammitgliedern stießen wir regelmäßig auf das Problem, dass sie im Spannungsfeld zwischen ihrem Linienvorgesetzten und dem Projektleiter standen. Aufgrund der unklaren Rollen gab es gegenseitige Schuldzuweisungen und Zweifel an der Kompetenz der Akteure, was zu Konflikten, hohen Reibungsverlusten und Frust bei allen Beteiligten führte.

Darüber hinaus förderten die Gespräche zu Tage, dass die Aufgaben und Arbeitsweise der einzelnen Projektgremien nicht so klar definiert waren wie immer gedacht. Wie oft tagt das Projektteam? Wer gehört dazu, wer nicht? Reicht ein Projektteam oder braucht man auch "Subteams" in einem Projekt? Wofür ist der Steuerkreis da? Was genau entscheidet der – was nicht? Brauchen wir unterschiedliche Steuerkreise, oder reicht einer? Wie oft trifft der sich? Wer leitet den und wie wird darin gearbeitet?

Kein gemeinsames Vorgehen

Beim Prozess der Projektabwicklung konnten wir beobachten, dass es weder bei den Entwicklungsprozessen, noch beim PM-Prozess sowie der Verkoppelung der beiden Prozesse ein einheitliches Verständnis gab – geschweige denn ein gemeinsames Vorgehen. Wie genau werden die Projekte abgewickelt? Wann machen Meilensteine und Status-Reviews Sinn? Welche Ressourcen setzt man wann und wo ein? Wie steuert man Ressourcenengpässe und setzt Prioritäten? Die Folge war, dass häufig unnötige Entwicklungsschleifen gedreht werden mussten und Termine sowie Budget nicht mehr zu halten waren.

Hoher bürokratischer Aufwand