von Jan Rauwerdink

Sag mir, wie dein Projekt beginnt und ich sage dir, wie es endet! Diese alte Projektweisheit trifft den Nagel auf den Kopf. Reviews vieler Projekte zeigen, dass die Ursachen für nicht erreichte Projektziele in aller Regel zu Beginn des Projektes zu suchen sind.

Wenn ich heute in einem Seminar oder bei einem Vortrag die Teilnehmer frage wie zufrieden sie mit den Ergebnissen, der Effektivität und der Zusammenarbeit in ihren Entwicklungsprojekten sind, bricht der aufgestaute Frust los:

Unser Kunde ändert ständig seine Anforderungen, obwohl wir eine mit ihm abgestimmte Spezifikation haben“

Den mit dem Kunden vereinbarte Termin nimmt bei uns niemand mehr ernst, um ihn zu halten bräuchten wir mehr Ressourcen und die bekommen wir nicht“

Mein Chef sagt zu mir: Sie immer mit ihren sogenannten Fakten und ewigen Bedenken, wir müssen dieses Projekt unbedingt stemmen, sehen Sie zu daß es klappt!“

Diese und andere Klagen mehr kennen viele von Ihnen aus dem eigenen Projekt.

Trotz etwa 40 Jahren Anwendung von Projektmanagement-Methoden und Tools in der Produktentwicklung, schaffen es viele Unternehmen nach wie vor nicht, ihre Projekte so zu planen und zu steuern, dass sie sicher und ohne grosse Reibungsverluste ihre Ziele erreichen.

Meine Erfahrung aus vielen Projekt-Reviews zeigt, dass am Projektanfang, noch vor der eigentlichen Planung von Aktivitäten,Terminen, Budgets und Ressourcen, ausreichend Zeit eingeplant werden muß für die Diskussion folgender Themen:

  • Für wen machen wir das Projekt: Wer ist Auftraggeber? Wer ist Kunde
  • Wer ist sonst noch vom Projekt betroffen oder daran beteiligt
  • Welche Bedürfnisse haben diese Personengruppen, die sogenannten Stakeholder
  • Welche Ziele müßen wir deshalb verfolgen
  • Welche Stärken und Schwächen unseres Unternehmens und der Projektmannschaft beeinflussen die Zielerreichung?
  • Welche externen Chancen bieten sich dem Projekt und welche Risiken aus dem Umfeld drohen?

Die Klärung dieser Schlüsselthemen wird in vielen Unternehmen nicht intensiv genug durchgeführt, die nicht gelösten Probleme holen das Projektteam dann später im Projekt wieder ein, führen zu den obenerwähnten Frustationen und müssen mit erheblichen Mehraufwand bewältigt werden.

Was kann man an der heutigen Praxis verbessern?

In der Praxis werden Produktentwicklungsprojekte zunächst grob beschrieben, und dann mit den wichtigsten Zielen für Funktionalität, Kosten und Termine etwas genauer umrissen.

Typische Beispiele:

  • Wir brauchen einen Nachfolger für unser Produkt. Es sollte vor allem die neuen Features, die der Wettbewerb bereits erfolgreich eingeführt hat, aufweisen.
  • Unser Produkt ist nicht mehr wettbewerbsfähig, wir müssen die Kosten dringend um 20% senken, und das innerhalb der nächsten 12 Monaten.
  • Unser Schlüsselkunde hat ein neues Produkt mit folgende Kenndaten angefragt, können wir das anbieten?

Wenn im Management über die Globalziele Einigkeit besteht, wird in der Regel das Marketing beauftragt, zusammen mit der Entwicklung und dem Controlling ein Produktkonzept auszuarbeiten und die Wirtschaftlichkeit des Projekts zu prüfen. Marketing und Entwicklung überlegen sich dann, wie das neue Produkt genau aussehen soll und schreiben eine detaillierte technische Spezifikation. Wird das Produktkonzept vom Management genehmigt, fängt in den meisten Fällen unmittelbar die Entwicklungsarbeit an.

Erst vor kurzem habe ich in einem Entwicklungsprojekt wieder erlebt wie die gemeinsam mit dem Kunden verabschiedete Spezifikation in der Prototypphase noch einmal erheblich geändert werden mußte. Die Bedürfnisse der Servicetechniker des OEM-Kunden waren nicht ausreichend berücksichtigt. Die Ansprechpartner des Auftraggebers kannten die Bedürfnisse ihrer Kollegen aus dem Kundendienst zu wenig. Als diese den ersten Prototyp zu Gesicht bekamen, fielen ihnen die Mängel sofort auf und es wurde ein Redesign beschlossen. Daß Termine, Herstellkostenziele und Projektbudgets nicht verändert wurden, war auf Managementebene selbstredend.

Deswegen macht es Sinn im Projektablauf eine Zwischenphase einzufügen, um genau zu klären welche Stakeholder am Projekt beteiligt sind, welche Ziele sich aus deren Bedürfnissen ableiten und welche Risiken die Zielerreichung bedrohen.

Der erste Schritt in dieser Zwischenphase ist eine Stakeholderanalyse. Nach DIN 69905 sind dies Personen oder Personengruppen, die am Projekt beteiligt, am Projektablauf interessiert oder von den Auswirkungen des Projektes betroffen sind.

Zum Beispiel:

  • die Unternehmensführung
  • der Kundendienst
  • die Entwicklung
  • der Vertrieb
  • die Produktion
  • das Controlling
  • die Kunden
  • die Wettbewerber
  • der Gesetzgebe
  • die Lieferanten

In dieser Zwischenphase ist es sinnvoll, wenn das Projektteam zunächst zusammen mit erfahrenen Kollegen aus früheren Projekten, überlegt welche Stakeholder dort beteiligt waren und welche Bedürfnisse diese hatten. Anschliessend wird gemeinsam untersucht was im derzeitigen Projekt neu bzw. anders ist und welche Stakeholder zusätzlich in Betracht gezogen werden müssen. In einem moderierten Brainstorming wird dann eine ausführliche Liste aller Stakeholder erstellt.

Im zweiten Schritt werden dann die Bedürfnisse der verschiedenen Stakeholder untersucht und dokumentiert. Meistens verfügen die Marketing- und Entwicklungsverant-wortlichen über entsprechende Erfahrungen. Ist dies nicht der Fall, sollten Gespräche oder Workshops mit den jeweiligen Stakeholdern durchgeführt werden um deren Bedürfnisse aus erster Hand kennen zu lernen.

Neben der Untersuchung der Bedürfnisse wird auch bewertet, welchen Einfluß der jeweilige Stakeholder auf das Projekt ausübt und welches Interesse er am Projekt hat.

Es gibt Stakeholder, die zwar eine sehr große Macht über das Projekt haben aber kein oder wenig Interesse. Beispiele sind Gesetzgeber, Prüfbehörden oder andere Instanzen. Andere Stakeholder, wie zum Beispiel Mitarbeiter des eigenen Unternehmens die nicht direkt am Projekt beteiligt sind, haben unter Umständen ein sehr großes Interesse aber kaum Einfluß.

Durch die Bewertung dieser beiden Faktoren können wir anschließend unsere Stakeholder einer der vier nachfolgenden Kategorien zuordnen:

1. Stakeholder die viel Macht und großes Interesse am Projekt haben

2. Stakeholder die viel Macht aber kaum Interesse haben

3. Stakeholder die kaum Macht aber viel Interesse am Projekt haben

4. Stakeholder die weder Macht noch Interesse am Projekt haben

Diese Einordnung bestimmt, wie intensiv das Projekteam mit den jeweiligen Stakeholdern Kontakt halten sollte. Mit Stakeholdern der ersten Kategorie sollte das Projektteam während der gesamten Laufzeit des Projektes intensiven, auch informellen Kontakt halten.

Im nächsten Artikel auf diesem Blog erfahren Sie,wie die Bedürfnisse der Stakeholder in Ziele für das Projekt umgewandelt werden.

Die Bewertung der Stärken, Schwächen, Chancen und Risiken und die Ableitung einer zielführenden Projektstrategie wird in ein weiterer Artikel erläutert.

Bitte weisen Sie auch Ihre Kollegen und Freunde auf diesen Blog hin.

Ihr

Jan Rauwerdink

Highlights

Das 48-seitige Buch "Gute Gründe Projekt-ingenieur VDI zu werden" ist fertig!



Sie erfahren welchen Nutzen der Lehrgang "Projektingenieur VDI" seinen Absolventen bietet und lernen die Inhalte detailliert kennen.
Sie können das Buch als Pdf-File hier herunterladen! Wenn Sie uns eine Mail senden, lassen wir Ihnen auch gerne ein gedrucktes Exemplar zukommen.

Video "Projekt-strukturierung" 

Klare Strukturen sind die Voraussetzung für den Erfolg! In diesem Video lernen Sie die 4 wichtig-sten Elemente für die erfolgreiche Struktur-ierung von Projekten kennen.
zum Video...

Wertanalyse Video
Lernen Sie die wichtig-sten Elemente der Wertanalyse kennen!
zur Wertanalyse...


Projektleiter Coaching
Wie Ihre Projektleiter zur Höchstform auflaufen ...
zum Coaching Programm ...