Wann ist ein Projekt (k)ein Projekt?

Erfolgt die Abgrenzung von Projektarbeit und Tagesgeschäft nicht nach eindeutigen Kriterien, entscheiden die Mitarbeiter nach eigenen Maßstäben, ob ihre Aktivitäten als Projekt gelten oder nicht. Die Folgen sind "Projektitis" oder "Under-cover-Projekte". Thomas Haas schildert, wie ein inhabergeführtes Maschinenbauunternehmen mit seinem PM-System erst einmal scheiterte, dann aber passende Abgrenzungskriterien für seine individuelle Situation fand. Der Erfahrungsbericht behandelt typische Schwierigkeiten bei der Einführung eines PM-Systems und stellt eine tragfähige Lösung vor.

 

Wann ist ein Projekt (k)ein Projekt?

Erfolgt die Abgrenzung von Projektarbeit und Tagesgeschäft nicht nach eindeutigen Kriterien, entscheiden die Mitarbeiter nach eigenen Maßstäben, ob ihre Aktivitäten als Projekt gelten oder nicht. Die Folgen sind "Projektitis" oder "Under-cover-Projekte". Thomas Haas schildert, wie ein inhabergeführtes Maschinenbauunternehmen mit seinem PM-System erst einmal scheiterte, dann aber passende Abgrenzungskriterien für seine individuelle Situation fand. Der Erfahrungsbericht behandelt typische Schwierigkeiten bei der Einführung eines PM-Systems und stellt eine tragfähige Lösung vor.

 

Damit ein Projektmanagementsystem auf Dauer bestehen kann, müssen Kriterien festgelegt werden, anhand derer Projekt- und Tagesgeschäft klar voneinander unterschieden werden können. Sind die Abgrenzungskriterien "dehnbar" und lassen sie Raum für Interpretationen, besteht die Gefahr, dass die Mitarbeiter bei der Projektabgrenzung eigene Maßstäbe anlegen. Als Konsequenz kann der angestrebte Nutzen des Projektmanagementsystems nicht realisiert werden und das System scheitert.

Im Folgenden wird am Beispiel eines Maschinenbauunternehmens dargestellt, wie sich unpräzise Abgrenzungskriterien auf die Projektarbeit, die Mitarbeiter und das Unternehmen auswirken können. Weiterhin wird ein erprobter Lösungsansatz für die Abgrenzung beschrieben, der in dem betreffenden Unternehmen erfolgreich umgesetzt wurde.

Die Ausgangslage

Das Unternehmen
Die hier beschriebene Firma ist ein inhabergeführtes Maschinenbauunternehmen mit ca. 800 Mitarbeitern weltweit. Die Wertschöpfungskette reicht vom Einkauf des Rohmaterials über die Bearbeitungsschritte Lasern, Biegen, Schweißen, Schleifen und Montieren bis zum fertigen Endprodukt. Als Systemanbieter in einer funktionalen Organisation bietet das Unternehmen folgende Produktpalette an: Maschinen in Einzel- und Serienfertigung mit entsprechendem Zubehör sowie den Bereich After Sales (Ersatzteile, Verbrauchsmaterial und Kundendienst). Der Absatz konzentriert sich vor allem auf Europa und Asien und wird zu einem großen Teil über den Fachhandel abgewickelt.

In einem inhabergeführten Maschinenbauunternehmen war die bereichsübergreifende Zusammenarbeit in den letzten fünf Jahren massiv angestiegen. Grund dafür war die Verkürzung der Produktlebenszyklen und die Technologisierung der funktional übergreifenden Unternehmensprozesse, also die Integration bzw. Vernetzung der Prozesse durch neue Technologien (ERP, webbasierte Lösungen, Dokumentenmanagement usw.). Aus dieser Situation heraus entstanden vornehmlich Entwicklungsprojekte für neue Maschinenreihen bzw. Produktfelder und DV-Projekte zur Einführung von 3D-CAD, CRM, E-Commerce oder CMS. Die Zielerreichung (Kosten, Qualität, Zeit) einzelner Projekte lag dabei teilweise nur bei 50% und darunter. Die Geschäftsleitung bemängelte vor allem die fehlende Transparenz. Unter diesen Bedingungen war es ihr nicht möglich, die Projektaktivitäten übergeordnet zu steuern.

Auf Beschluss der monatlichen Geschäftsleiter-Runde erging deshalb an die Leitung Datenverarbeitung & Organisation (DVO) der Auftrag, ein unternehmensübergreifendes Projektmanagementsystem für die deutschen Standorte auszuarbeiten. Ziel war es, eine Verfahrensanweisung ("Projektmanagementhandbuch") zur systematischen Abwicklung von Projekten im Unternehmen zu erstellen. Der Abteilungsleiter DVO stellte daraufhin ein Projektteam zusammen, das aus Mitarbeitern aller funktionaler Bereiche bestand. Mit Hilfe von PM-Literatur entwickelte er ein Projektmanagementhandbuch, das an die spezifischen Anforderungen des Unternehmens angepasst war.

Erster Versuch: Projektmanagement 1.0

Der erste Anlauf zur Implementierung des Projektmanagementsystems fand 2003/2004 statt. Um die Projekte vom Tagesgeschäft abzugrenzen, wurden die folgenden Aussagen aus dem Projektmanagementhandbuch verwendet:

Ein Projekt

  • ist ein zeitlich befristetes, einmaliges Vorhaben zur Erreichung vorab definierter Ziele.
  • wird von einem Team unter vorab definierten Rahmenbedingungen zu Zeit, Kosten, Qualität bearbeitet.
  • erfordert kontinuierliche Planung und Steuerung durch einen Projektleiter.
  • ist abteilungsübergreifend und verursacht Kosten von mehr als 25.000 Euro.

Die meisten von dem Regelwerk betroffenen Mitarbeiter erklärten in inoffiziellen Gesprächen mit dem zuständigen Controller (Administrator Projektmanagement), dass sie auf Basis solch dehnbarer Kriterien keine für sie vernünftige Einteilung von Projekt- und Tagesgeschäft vornehmen könnten. Aus ihrer Sicht handelte es sich um Allgemeinplätze. Sogar der scheinbar eindeutig quantitative Begriff "Kosten" war zu unpräzise definiert. So blieb unklar, ob mit diesem Posten externe bzw. interne Personalkosten, Investitionen, Folge- oder Opportunitätskosten gemeint waren. Der Administrator Projektmanagement musste feststellen, dass kein unternehmensweiter, grundlegender Konsens darüber existierte, welche Aktivitäten als Projekt zu klassifizieren waren. Das führte dazu, dass im weiteren Verlauf der Anwendungsphase bei persönlichen Einzelfallentscheidungen zwei völlig gegensätzliche Phänomene ausgebildet wurden: Projektitis und Under-cover-Projekte.

Projektitis

Ein Teil der Mitarbeiter definierte beinahe alle Aktivitäten als Projekt (Projektitis). Dieses Vorgehen erschien ihnen dienlich, um für die eigenen Belange Ressourcen zu erkämpfen und persönliche Ziele zu erreichen, z.B. die Erlangung des im Unternehmen angesehenen Status eines Projektleiters (dem Eigenschaften wie Führungskompetenz oder Stressresistenz zugeschrieben werden). Deshalb deklarierten sie ihr Tagesgeschäft wie z.B. die Produktpflege oder kleine Rationalisierungsmaßnahmen als Projektaktivitäten und ernannten sich selbst zu Projektleitern. Die Wichtigkeit ihrer Projekte gaben sie gerne als sehr hoch an und beriefen sich darauf, wenn sie beispielsweise bei den Leitern der Fachabteilungen nach Ressourcen fragten.

Die Leiter der Fachabteilungen bauten eine starke Blockadehaltung gegenüber allen Projekten auf. Dabei verwiesen sie auf die formalen Regelungen des Projektmanagements. Insbesondere setzten sie Rückfragen nach vorhandenen Projektkonzepten und –verträgen ein. Auf diese Weise hinterfragten sie…

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 22
Kommentare 0