Einführung von Projektmanagement in einem mittelständischen Industrieunternehmen

Mai 6, 2015 8:28 am Veröffentlicht von Dr. Susanne Stolt

Was war der Ausgangspunkt, was war unser Auftrag?

Wie viele mittelständische Unternehmen wollte unser Kunde ein neues, verbessertes Vorgehen für das Managen von Entwicklungsprojekten erreichen. Die Abteilung Entwicklung war in der zurückliegenden Zeit deutlich aufgestockt worden, weil man schneller und mit besseren Produkten auf die sich wandelnden Anforderungen des Marktes reagieren wollte. In der Vergangenheit ließen sich die Produkte in enger Abstimmung über alle Bereiche hinweg entwickeln, aber nun genügte dieses Vorgehen aufgrund einer wachsenden Zahl von Mitarbeitern und daraus folgenden Problemen bei der Abstimmung nicht mehr. Da es auch immer wieder Konflikte zwischen den Vertretern der verschiedenen Abteilungen gab und Klagen über die „ungenügende“ Arbeit der Entwicklung, wurde den Entscheidern klar, dass eine grundsätzlich neue Lösung gefunden werden musste und dass dafür eine externe Unterstützung sinnvoll sein würde. Unser Auftrag lautete, bei der Einführung eines effektiveren Projektmanagements zu unterstützen. Wir starteten mit dem Kunden einen längeren Change-Prozess, mit dem Ziel, ein neues, verbessertes Projektmanagement im Rahmen des Produktentwicklungsprozesses zu schaffen und einzuführen.

Was waren die wesentlichen Schritte zur Veränderung?

a) Start
Um diesen Prozess zu organisieren, gründeten wir ein Projekt. Startpunkt war zunächst ein Workshop mit dem oberen Management, wo eine gemeinsame Sicht auf die vorhandenen Probleme und den Lösungsweg geschaffen sowie der Rahmen für das Projekt mit Projektteam und Terminen definiert wurde. Die Probleme, die zusammengetragen wurden, waren z.B.:

  • zu lange Entwicklungszeiten
  • unnötige Entwicklungsschleifen, weil nicht alle Fachsichten berücksichtigt wurden (z.B. Produktion: die entwickelten Produkte ließen sich technisch so nicht herstellen bzw. nicht ohne Mehraufwand oder zusätzliche Investitionen)
  • unklare Anforderungen und zu viele Änderungen im Produktentwicklungsprozess
  • unklare Zuständigkeiten, Konflikte zwischen Personen und Abteilungen
  • unklares Vorgehen bei der Projektbearbeitung

Wichtig war auch, die vorhandenen Potentiale und Stärken zum Ausgangspunkt zu nehmen. Ein entwickeltes technisches Know-how in Entwicklung und Fertigung, hohe Flexibilität gegenüber Kundenwünschen, kurze Entscheidungswege und enge Kommunikation sowie eine flache Hierarchie waren entscheidende Stärken, die auch in Zukunft genutzt werden sollten.

b) Konzeptphase
Im Rahmen des Stark-Workshops wurde ein Konzept-Team gegründet, das aus erfahrenen Vertretern aller involvierten Fachbereiche bestand. Dieses Team hatte die Aufgabe, ein zukünftiges Vorgehen in der abteilungsübergreifenden Produktentwicklung zu definieren. Weil alle beteiligten Fachbereiche im Konzeptteam vertreten waren, konnten wir sicher gehen, dass das Vorgehen, das gemeinsam entwickelt wurde, eine hohe Praxisrelevanz besitzen würde und deshalb auch von allen Fachabteilungen abgenommen werden würde. Als Berater zielten wir mit der Bildung dieses abteilungsübergreifenden Team gleichzeitig auf etwas anderes, nämlich dass das abteilungsübergreifende Denken und Abstimmen bereits eingeübt werden und vorhandene Konflikte thematisiert und aufgearbeitet werden sollten. Das Konzeptteam sollte zu einem Nukleus für die kulturelle Veränderung werden.
Im Start-Workshop war die Verärgerung einiger Abteilungsleiter deutlich geworden, bei der Produktentwicklung nicht gehört und berücksichtigt zu werden und dann hinterher den Schaden ausbaden zu müssen. Das zeigte uns, dass hier – wie in den meisten Unternehmen – ein sequenzielles, abgeschottetes Vorgehen vorhanden war („jeder wirft dann seinen Teil über den Zaun zur nächsten Abteilung“), das sich letztlich mit der klassischen funktionalen Struktur, also Aufteilung in fachspezifischen Abteilungen, erklären lässt. Mit der Arbeit im Konzeptteam konnte diese Silo-Struktur und das Silo-Denken bereits überbrückt werden, indem alle Fachsichten in die Lösungen einfließen konnten. Die aufgestauten Konflikte wurden im Rahmen der sechs Workshoptage bearbeitet. Auch das war ein wichtiges Lernfeld, weil es das Verstehen der unterschiedlichen Interessen, Anforderungen und Fachsichten möglich machte. Dabei wuchs auch das persönliche Verständnis füreinander.
Am Ende hatte das Konzeptteam ausgehandelt und abgestimmt,

  • was die einzelnen Schritte in der technischen Produktentwicklung sind und wer wofür verantwortlich ist in diesem technischen Produktentwicklungsprozess
  • welche Rollen es bei der Projektbearbeitung gibt und welche Aufgaben und Verantwortung genau verknüpft sind mit den jeweiligen Rollen im Projektmanagement
  • wie Projekte bearbeitet werden, also z.B. wie Projekte initiiert, definiert und geplant werden sollten und was zu den einzelnen Meilensteinen und Produktentwicklungsstufen alles überprüfbar fertiggestellt sein sollte.
  • wie der Produktentwicklungsprozess und die Projektabwicklung ineinander greifen und wie gleichzeitig laufende Projekte übergreifende gesteuert werden und die Ressourcen gemanaged werden
  • wie die Projektteams zusammengesetzt sind und was die Anforderungen an die Zusammenarbeit sind.

Die Ergebnisse wurden in einem kurzen, übersichtlichen Projektmanagement-Handbuch festgehalten. Das PM-Handbuch wurde zunächst noch als Entwurf gesehen. Zwar wurden die Rollen, Prozesse und sonstigen Festlegungen schon im Rahmen der Workshop-Reihe immer wieder in den jeweiligen Abteilungen vorgestellt und diskutiert. Aber das beschriebenen Vorgehen, wie Projekte in Zukunft schneller und besser bearbeitet werden sollten im Unternehmen, sollte bis zum Schluss offen bleiben für das Feedback und die Verbesserungen der anderen Kollegen.
Am Ende hatten wir jedoch nicht nur den Entwurf für ein neues Projektmanagement-Handbuch, sondern ebenso eine Gruppe von Abteilungsleitern, die ein besseres Verständnis füreinander entwickelt hatten und die ein Idee davon hatten, wie wichtig die direkte und gemeinsame Abstimmung bei der Produktentwicklung (und anderen Themen auch!) ist. In späteren Phasen wurde das immer wieder von den Beteiligten betont: Dadurch, dass sie gemeinsam im Konzeptteam um ein besseres Vorgehen gerungen hatten, hatten sie verstanden, worauf es letztlich in der Projektbearbeitung auch ankommt: das Wahrnehmen und Aushandeln unterschiedlicher fachlicher (und menschlicher) Sichtweisen. Auf dieser Basis war der erste Schritt zu einer Kulturveränderung vollzogen, die notwendig ist, wenn eine Projektmatrixorganisation wirklich funktionieren soll.
Der Entwurf des PM-Handbuchs wurde dann den Mitgliedern der Geschäftsführung vorgestellt und von diesen grundsätzlich genehmigt.

c) Roll-Out-Phase
Es wäre zu einfach zu glauben, dass ein PM-Handbuch – auch wenn es intern von Vertretern aller Bereiche oder sogar von verschiedenen Abteilungsleitern entwickelt wurde – einfach per Dekret im Unternehmen angenommen würde. Aus unserer Erfahrung ist es immer notwendig, die Mitarbeiter dazu nicht nur zu informieren, sondern auch dafür zu gewinnen. Warum? Weil diese Vorgehensweise das Ineinandergreifen von mehreren Abteilungen und Bereichen voraussetzt. Und es gibt keine Führungsfunktion im Unternehmen, die in der Lage wäre, dieses übergreifende Zusammenspiel allein durchzusetzen. Um Projektmanagement als Zusammenspiel vieler Bereiche zu erreichen, braucht man Mitarbeiter und Führungskräfte, die davon überzeugt sind, dass Projektarbeit so am besten funktionieren wird.
In anderen Unternehmen haben wir häufig erlebt, dass es die Abteilungsleiter waren, die sich gegen das Projektmanagement wehrten. Schließlich bedeutet Projektmanagement, dass ihre Mitarbeiter in Projekten tätig werden, ihnen also Kapazitäten für das „normale“ Tagesgeschäft verloren gehen. Zudem verlangt Projektarbeit, dass Projektmitarbeiter im Projektteam Informationen teilen und entscheiden – dass also der Abteilungsleiter Macht und Einfluss an das Projekt und den Projektmitarbeiter abgibt. In der Regel kommt es also zum bekannten Konflikt zwischen Linienabteilung und Projekt, einem der typischen Probleme der Projektmatrixorganisation.
In diesem Beispielunternehmen war dieses Problem nicht so auffällig, weil es Abteilungsleiter sind, die Projekte leiten und diese im Konzeptteam am PM-Handbuch-Entwurf mitgearbeitet haben.
Für das Implementieren des neuen Vorgehens in das Unternehmen haben wir Schulungen für die Mitarbeiter aller Bereiche organisiert, die an der Projektbearbeitung beteiligt waren oder in Zukunft sein sollten. Diese Schulungen haben wir nicht selbst durchgeführt, sondern stattdessen die Abteilungsleiter dabei unterstützt, ihre Mitarbeiter selbst zu schulen. Die Abteilungsleiter haben wir unterstützt, indem wir das Schulungskonzept entworfen und sie auf die Schulung ihrer Mitarbeiter vorbereitet haben.

Meistens waren wir bei den Schulungen auch anwesend. Erstaunlich war, dass die Mitarbeiter das neue Vorgehen überwiegend akzeptierten. Sie hatten zwar Nachfragen und Ergänzungen. Aber generell fanden die Mitarbeiter das neue Vorgehen besser als das, was sie bisher hatten. Sehr positiv haben sich alle über die Schulungen selbst geäußert, weil sie sich dadurch gut informiert und auch einbezogen fühlten.

d) Stabilisierungsphase
Mit dem Roll-out war die Reise zu einer Projektmatrixorganisation und der dazugehörigen, projektorientierten Kultur aber noch nicht zu Ende. Eine halbtägige Schulung genügt eben nicht, um neue Strukturen und eine neue Kultur im Unternehmen zu verankern. Das ist generell so. Mit dem Verabschieden des neuen PM-Handbuchs und den Schulungen aller Mitarbeiter ist zwar der Startschuss erfolgt. Was folgte, war eine längere Phase der Unsicherheit, wo die neuen Vorgehensweisen ausprobiert, eingeübt, überprüft wieder nachjustiert wurden. Bei unserem Kunden war diese schwierige Übergangsphase sehr deutlich zu beobachten. Und sie ist auch immer noch im Gange. Man kann diese Phase nicht überspringen oder umgehen. Denn hier findet die eigentliche Implementierung statt und Kultur verändert sich nur langsam. Aber man kann und sollte diesen Entwicklungsprozess begleiten und unterstützen. Maßnahmen dafür sind beispielsweise:

  • Trainings für die Projektleiter und Projektmitarbeiter
  • Coachings in schwierigen Situationen für Projektleiter
  • Konfliktklärung
  • Trainings für die Abteilungsleiter, in diesem Fall auch damit sie mit ihrer Doppelrolle als Projektleiter und Abteilungsleiter besser klar kommen
  • Workshops in den Abteilungen
  • Evaluation und Nachbessern des PM-Handbuchs bzw. der Festlegungen zu Rollen und Prozesse.

Ein Teil dieser unterstützenden Maßnahmen hat dieser Beispielkunde umgesetzt. Aber das Signal an uns war zunächst: Wir wollen es selbst ausprobieren und lernen. Das ist verständlich und gut. Denn das ist die Basis dafür, dass das neue System anfängt zu leben.
Vor kurzem haben wir die Evaluation durchgeführt. Es sind noch einige Maßnahmen notwendig, um den eingeschlagenen Weg zu Ende zu gehen. Aber sehr viel, so ein Ergebnis der Evaluation, ist schon erreicht.

Kategorisiert in:

Dieser Artikel wurde verfasst von Dr. Susanne Stolt