Staus im Produktemanagement

Beim gestrigen Lunch machte mich mein Gesprächspartner auf eine Tatsache aufmerksam, die für Migrations- und Integrationsprojekte (MIP) typisch ist. Die zum Einsatz gelangenden Produkte sollten zwar möglichst neu sein, ohne jedoch die Mängel von Kinderkrankheiten aufzuweisen. Meistens gibt es nur eine oder zwei Personen, die das Produkt wirklich gut kennen. Nicht einmal die Entwickler kennen das Produkt, da sie im Allgemeinen nur an einem bestimmten Modul gearbeitet haben. Der Architekt und der Entwicklungschef kennen das Produkt bloss konzeptionell, aber haben auch keine Erfahrung, wie sich das Produkt im Betrieb verhält. So gibt es wohl nur den Produktmanager innerhalb der Entwicklung, der sich mit dem Produkt in praxi wirklich auskennt. Die Projektleiter, die das Produkt bei den Kunden in aller Welt ausrollen müssen, haben oft keine Produktkenntnisse, und die Mitarbeiter der nationalen Konzerngesellschaften des Lieferanten noch viel weniger.

So muss denn nun der zentrale Produktmanager zunächst seine Kollegen von den Projekten und der Trainingsabteilung schulen. Das kann er aber nicht fulltime tun, denn er muss ja auch immer das Produkt im Auge behalten. Wenn z.B. ein Trainer der Schulungsabteilung eine Frage der Kursteilnehmer nicht beantworten kann, leitete er sie an den Produktmanager weiter, denn auch der Trainer kennt das Produkt bloss theoretisch. Später, wenn sich das Produkt in einer bestimmten Kundenumgebung eigensinnig benimmt, werden die lokalen Ressourcen und der zentrale Projektmanager, versuchen, die Fehler zu reproduzieren und zu dokumentieren. Nur der zentrale Produktmanager kann abschliessend sagen, ob es sich um einen Konfigurationsfehler oder um einen Produktfehler handelt. Es kommt zu Staus und der Propagationsprozess der Produktkenntnisse zieht sich schleppend dahin. Was Sie in meinem gestrigen Artikel über Verzögerungen gelesen haben, lässt hier grüssen. Wir werden darauf zurück kommen.

Was macht man mit Bottlenecks? Gemäss Eliyahu M. Goldratt1 versucht man, die Engpassressource auszubauen. Bis es soweit ist, muss sich alles andere nach dem Engpass richten. Das bedeutet, dass andere Einheiten Wartezeiten haben werden. Auf keinen Fall dürfen die anderen Einheiten weiter arbeiten, denn das baut nur Bestände auf. In MI-Projekten sind das lange Issues- und Aktionslisten (siehe Komplexität im Projektmanagement). Das Projekt zieht sich schleppend dahin, bis das Produkt-Know-How genügend weit zum Kunden hin propagiert ist, dass sich das Projekt ohne zentrale Experten komfortabel durchführen lässt. Das kann aber dauern. Umgekehrt bedeutet die Ausweitung der Engpassressource zwei oder gar drei Produktmanager parallel laufen lassen. Bloss ist keine Kunde bereit, das zu zahlen.

Er wird aber auch nicht bereit sein, das Projekt zu verzögern. Im Gegenteil wird er mit Penalties drohen, das ist vorprogrammiert. Hier muss die nationale Konzerngesellschaft handeln, bevor ein entsprechendes Projekt kommt. Die lokalen Produktmanager müssen rechtzeitig aufgebaut werden, andernfalls baden es die lokalen Projektressourcen aus und das Unternehmen wird einen Imageverlust erleiden.

1Eliyahu M. Goldratt, Jeff Cox. Das Ziel – Höchstleistungen in der Fertigung. McGraw-Hill Book Company, Maidenhead 1990
und
Eliyahu M. Goldratt. Die Kritische Kette – Das neue Konzept im Projektmanagement. Campus Verlag. Frankfurt a. Main 2002

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.