Wie kann man verhindern, dass gut gemeinte Projektmanager sich zu sehr in die Details einmischen?

Bei der Arbeit an Projekten gibt es oft Projektmanager, die aus technischen Rollen gewechselt sind.

Ob gut oder schlecht, diese Projektmanager übernehmen oft die Führung bei der Definition der technischen Ergebnisse, oft auf die Gefahr hin, die technischen Teams zu entfremden, fehlende Abhängigkeiten, Einschränkungen usw., die technische Errungenschaften usw. definieren.

Manchmal kommt ein Projektmanager vorbei, der grundlegende Erfahrungen mit technischen Lösungen gemacht hat und versucht, technische Meilensteine ​​zu definieren.

Anstatt ihnen dann zu sagen, dass es nicht ihre Aufgabe ist, diese zu definieren (da dies zu unbeabsichtigten Ergebnissen führen kann, z. B. Konflikte, herausfordernde Egos usw.), was wäre ein angemessener Ansatz oder eine Reihe von Ansätzen?

Antworten (3)

Es gibt sicherlich Menschen, die nicht anders können, als aus ihrer Schwimmbahn zu springen und sich dort einzumischen, wo sie nicht sein sollten. Wenn das passiert, schlagen Sie direkt zu und lassen sie wissen, dass sie sich einmischen und den Erfolg gefährden. Der PM hat jedoch die Lizenz, aus der PM-Schwimmspur zu springen, und Sie können ihm/ihr nicht sagen, dass er Sie in Ruhe lassen soll.

Angenommen, Sie haben keinen chronischen Manager vom Typ Mikromanager, Ihr PM springt wegen Ihnen und Ihrem Team aus der PM-Swimlane. Es ist nicht der PM und die Lösung besteht darin, nicht herauszufinden, wie man mit dem PM umgeht. Sie und Ihr Team sind es, und die Lösung besteht darin, herauszufinden, was Ihr Team tut oder nicht tut, was dazu führt, dass sich der PM einmischt. Es fehlt an Vertrauen, an Leistung, wachsenden Risiken, Beschwerden, irgendwas.

Wenn Sie diesen Mikromanager-Typ PM haben, dann freuen Sie sich, dass Projekte ein Enddatum haben, an dem Sie ein anderes Projekt und einen anderen PM finden können.

Wenden Sie die gleichen Techniken an, die der PM angewendet haben sollte:

Wie Sie sagten (soweit ich es interpretiert habe), möchten Sie niemanden verärgern oder einen Konflikt auslösen.

Eine nette Möglichkeit ist es, ein Gespräch zu führen, indem man Fragen stellt (ich habe keine nette Referenz gefunden):

  • Was waren Ihre Annahmen, als Sie dieses Datum angegeben haben?
  • Wussten Sie, dass dieses Team diese Technologie noch nie zuvor angewendet hat?
  • ...

Wenn Sie es schaffen, interessiert nachzufragen, wird Ihr PM nicht aus der Fassung gebracht. Außerdem sollte der PM den Mangel an Wissen bemerken und in Zukunft eine Expertengruppe einrichten.

Nur zur Vollständigkeit der Antwort:

  • Manchmal ist es besser, einen Konflikt auszufechten, als etwas lange mit sich herumzuschleppen
  • Sind Ihre Projekte endlich erfolgreich (wrt Budget und Folgeverträge)? Vielleicht ist es der (hässliche) Weg, die Entwickler zu drängen oder einen Vertrag zu gewinnen – dann sollte man anders argumentieren (mehr kommerzieller Erfolg).

Nun, zuerst ist es wichtig, sich daran zu erinnern, dass ein PM, der sich versucht hat, möglicherweise nützliche Ratschläge oder Meinungen hat und diese möglicherweise nicht auf die richtige Weise ausdrückt. Es ist im besten Interesse aller Beteiligten, durch die Egos zu navigieren, um sicherzustellen, dass die bestmögliche Lösung geschaffen wird.

Abgesehen davon empfehle ich, mit dem PM zusammenzuarbeiten, um die tatsächlichen Kundenanforderungen zu ermitteln. Eine gute Möglichkeit, dies zu tun, besteht darin, einfach Sondierungsfragen zu stellen:

  1. Was die detaillierten Anforderungen sind.
  2. Wie war das Kundenfeedback.

Wenn sie beginnen, Implementierungslösungen anzubieten, erinnern Sie sie höflich daran, dass Sie sich auf die Grundanforderungen konzentrieren möchten und nicht darauf, wie Sie sie lösen würden.