Sind Projektmanager in einer Digitalagentur überflüssig?

Haftungsausschluss: Ich habe noch nie in einer Digitalagentur gearbeitet und bin mir bewusst, dass die Rolle des Projektmanagers in Digitalagenturen etwas anders sein kann als in anderen IT-Betrieben, ob intern oder bei Softwareentwicklungsanbietern. Außerdem sind mir die genauen Unterschiede nicht klar.

Trotz meines obigen Haftungsausschlusses und wenn ich die Frage und die Rollen für bare Münze nehme, denke ich, dass es eine Reihe von Problemen mit den hier gemachten Annahmen gibt:

1. Der Projekt-/Account-Manager ist kein Entwickler

Na und? Das sind sehr unterschiedliche Rollen mit sehr unterschiedlichen Verantwortlichkeiten. Meiner Erfahrung nach denken Entwickler oft, dass die Rolle des Projektmanagers in gewisser Weise mit der des Teamleiters oder Entwicklungsleiters verwandt ist. Zweifellos ist dies in einigen Organisationen in der Praxis der Fall, aber ich nehme an, dass dies hier nicht der Fall ist, da Sie bereits angegeben haben, dass Sie Dev Leads haben. Das ist also eher eine Tatsachenfeststellung als ein tatsächliches Problem. Es kann zu erheblichen Projektproblemen führen, wenn der PM eine technische Anerkennung benötigt, um seine PM-Arbeit abzuschließen, oder wenn das Entwicklungsteam die mangelnde technische Erfahrung des PM gegen sich ausnutzt, indem es beispielsweise die Arbeitsbelastung über- oder unterschätzt, wenn der PM dies nicht tut. Sie verfügen nicht über die erforderlichen Fähigkeiten, um Schätzungen zu überprüfen und anzufechten. Aber es ist an sich kein Problem.oder an das Projekt , da dadurch Probleme aufgedeckt werden, die angegangen werden können.

2. Der Effekt des chinesischen Flüsterns tritt auf und die Anforderungen gehen verloren/verwirren

Dies ist ein Prozessproblem. Sie verfügen nicht über ausreichend robuste Änderungsmanagement-, Anforderungserfassungs- und Protokollierungsprozesse, um sicherzustellen, dass Anforderungen nicht „verloren gehen“. Der PM sollte dies erkennen, auch wenn die Organisation dies nicht tut, und etwas lokal für das Projekt bereitstellen. Die Tatsache, dass Sie (und vermutlich im weiteren Sinne) der Rest des Entwicklerteams wissen, dass dies ein Problem ist, und Sie keine Lösung bereitgestellt haben, spricht hier jedoch für andere ungeschriebene Probleme. Es liegt in der Verantwortung aller , sicherzustellen, dass die Anforderungen ordnungsgemäß verwaltet werden.

3. Der Kunde möchte direkt mit den Entwicklern sprechen.

Es gibt keinen inhärenten Grund, warum dies ein Problem ist. Es kannein Problem sein, wenn die Entwickler nicht in der Lage sind, effektiv mit dem/den Kunden zu kommunizieren, und das ist in der weiteren IT-Welt oft der Fall. Beachten Sie, dass ich (hoffe ich) hier nicht stereotyp bin – Entwickler sind in der Hauptsache zielorientierte Detailmenschen, und oft möchten Kunden auf einer eher konzeptionellen Ebene mit anderen Agenden sprechen, die Entwickler nicht wahrnehmen. Umgekehrt können Kunden oft nicht die wahre Bedeutung und Konsequenz hinter den technischen Fragen der Entwickler erkennen. Es gibt immer Ausnahmen auf beiden Seiten und ich habe gesehen, dass es gut funktioniert, aber es funktioniert nicht immer. Wenn ein echter Kommunikationsbedarf zwischen Kunden und Entwicklern besteht, sollte dies vom PM erleichtert und verwaltet werden. Ich meine nicht, dass sie der Postbote zwischen den Gesprächen sein müssen oder bei jedem Treffen anwesend sein müssen,

4. Die Entwickler werden am Ende zu Projektmanagern.

Haben sie aber? Oder werden sie zu dem, was Entwickler für Projektmanager halten ? Fangen die Entwickler an, die Risiken der Arbeitgeber und der Kunden aktiv zu managen? Fangen sie an, über Ressourcenniveaus, Verträge und Erwartungen zu verhandeln? Ordnen sie den Projektplan neu, um neue Abhängigkeiten zu berücksichtigen und sicherzustellen, dass regelmäßige klare Kommunikationen gegen den Kommunikationsplan verlaufen? usw. usw. usw. Wenn sie wirklich anfangen , Projektmanager zu werden, dann haben Sie eindeutig einen ineffektiven Projektmanager. Oder haben Sie vielleicht einen PM, der unerfahren ist und nicht richtig kommuniziert oder nicht mit dem Entwicklungsteam zusammenarbeitet, um zu verstehen, was mit dem Projekt passiert?

Zusammenfassung/TL:DR

Mir scheint, dass all diese "Probleme" eigentlich Symptome sind. Keiner von ihnen ist für sich genommen ein echtes Problem (außer Punkt 2., der meines Erachtens ein Gruppenversagen ist).

Was ist also das Nettoergebnis dieser Symptome?

• Wird das Projekt zu spät geliefert?
• Überschreitet das Projekt das Budget?
• Ist die zu liefernde Qualität schlecht?
• Ist der Kunde unzufrieden?

Was Sie beschrieben haben, ist möglicherweise ein dysfunktionales Team, vielleicht mit einem unerfahrenen oder einfach nur Müll-PM, aber vielleicht auch nicht.

Beginnen Sie damit, zu definieren, was die tatsächlichen wesentlichen Probleme sind, und nicht, was Sie oder die Entwickler oder der PM für Probleme mit lokaler Arbeitspraxis halten. Es hört sich so an, als hätte sich ein gewisser Groll aufgebaut – versuchen Sie, darüber hinaus zu den eigentlichen Problemen zu sehen. Wenn Sie dann wissen, was tatsächlich falsch ist, können Sie als Unternehmen, als Team und als Einzelperson darüber nachdenken, was geändert werden muss, um die Situation zu korrigieren.

Erstens haben Sie noch kein Problem definiert. Kunden wollen mit Entwicklern sprechen – was ist daran falsch? Welche Auswirkungen hat das auf Umfang/Zeitplan/Kosten des Projekts? Auf irgendeiner anderen Projektmetrik?

• Gibt es einen Kommunikationsplan? Die Kommunikation zwischen Entwicklern und Kunden sollte vom Kommunikationsplan abgedeckt werden, der auch Bestimmungen enthalten sollte, um sicherzustellen, dass die richtigen Interessengruppen die Möglichkeit haben, an den Diskussionen teilzunehmen oder davon Kenntnis zu nehmen.

• Gibt es einen Anforderungsmanagementplan? Wenn die Anforderungen unklar sind, scheint es eine Möglichkeit zu geben, die Anforderungserfassung und -verwaltung zu verbessern. Wenn die Anforderungen verwaltet würden, würde das Problem vielleicht verringert werden?

• Gibt es eine Änderungskontrolle? Obwohl Sie es nicht gesagt haben, schließe ich daraus, dass das Problem darin besteht, dass, wenn die Kunden die Möglichkeit haben, mit den Entwicklern zu sprechen, die „Klärung“ der Anforderungen zu Änderungen des Umfangs/Zeitplans/Kosten/Qualität führt, die sich auf den Vertrag auswirken. Dies würde nicht passieren, wenn die Anforderungen dem Änderungsmanagement unterliegen würden.

Soweit ich das Problem verstehe, scheint es, dass der PM in mindestens einem Teil seiner Arbeit versagt. Die Lösung scheint darin zu bestehen, den PM zu coachen/trainieren/erweitern, um eine erfolgreiche Leistung zu ermöglichen.

Abgesehen davon: Ich würde auch empfehlen, sich die Stellenbeschreibung genau anzusehen, um sicherzustellen, dass das Unternehmen diese Fähigkeiten benötigt, und den Einstellungsprozess, um sicherzustellen, dass Sie sich für diese Fähigkeiten bewerben. Wenn die Intervention mit dem amtierenden Projektmanager fehlschlägt, möchten Sie sicherstellen, dass Sie das Problem nicht wiederholen. (aber ich denke, das liegt außerhalb des Rahmens von PM:SE)

Was das OP an den Tag legt, ist eine Voreingenommenheit und nutzt die Symptome seiner Organisation von scheinbarer Team-Unreife, Prozess-Unreife und vielleicht kulturellen Problemen als Beweis, um voreingenommenes Denken zu unterstützen.

Jede Rolle hat eine Reihe von Anforderungen an Kenntnisse, Fertigkeiten und Fähigkeiten, und jede Person, die eine Rolle einnimmt, verfügt über unterschiedliche Grade an Stärken und Schwächen, die diese Anforderungen an Wissen, Fähigkeiten und Fähigkeiten erfüllen. Einige von uns handhaben diese Schwächen besser als andere, wenn es darum geht, Lücken schließende Mitigatoren zu identifizieren, aber die meisten von uns, die nicht letztendlich aus der Rolle herausgewählt werden, finden einen Weg, um auf einem gewissen Niveau zu arbeiten.

Ein PM, dem ein technischer Bereich an Wissen und Fähigkeiten fehlt, der aber herausragende Stärken in den etwa 100 anderen Wissens- und Fähigkeitsanforderungen hat, kann sicherlich in der Rolle erfolgreich sein, wenn er anständige Lückenschließungsmilderungen für das findet, was er nicht weiß, während er seine Stärken ausschöpft in all diesen anderen Anforderungen.

Die Auswahlvalidität ist so schwer festzunageln, weil es keine Einheitsgröße gibt, die für alle passt. Die Anforderungen eines bestimmten Projekts zu einem bestimmten Zeitpunkt könnten einen nicht technischen PM erfordern, der an einem Punkt über herausragende Soft Skills für Kundenservice / Verkaufsfähigkeit verfügt und dann dorthin wechselt, wo ein sehr starker technischer PM besser wäre.

Als PM und ehemaliger Entwickler, der in einer Digitalagentur arbeitet, ist hier meine Meinung zu diesem Thema, basierend auf meiner Erfahrung und dem, was ich zuvor gesehen habe, als ich unter technischen Leitern gearbeitet habe (als ehemaliger Entwickler) und gesehen habe, wie Entwickler die Projekte zuvor in meiner jetzigen Form durchgeführt haben Unternehmen:

• Es gab keine wirkliche Struktur für die Art und Weise, wie die Projekte geliefert wurden, und obwohl das technische Team technisch in der Lage war, war dies nicht gleichbedeutend mit einer effizienten Kommunikation. Dies kam jedoch wirklich vor, als mehrere Personen an einem Projekt arbeiteten und das technische Team Probleme hatte, die Arbeit zu verteilen und den Zeitrahmen genau vorherzusagen.

Die Entwickler hatten einfach nicht die Vorstellungskraft, bestehende Prozesse zu verbessern, um die Effizienz zu steigern und die Art und Weise, wie Projekte geliefert wurden, zu verbessern.

• Das technische Team hatte Probleme beim effizienten Sammeln von Anforderungen, sehr oft betrachteten die Technikfreaks eine Anforderung zu technisch und nicht so, wie ein Benutzer sie sieht, und es fehlte das „Know-how“ für die Organisation von Anforderungen auf der Grundlage dessen, was den größten geschäftlichen Nutzen bringt. Dies ist eher eine Business-Analyst-Rolle als PM, aber ein PM sollte diese Fähigkeit besitzen.

• Den Technikfreaks, die zuvor die Projekte verwalteten, fehlten starke zwischenmenschliche Fähigkeiten, was ein Muss ist. Mitarbeiter motiviert zu halten, klingt einfach, kann aber sehr schwierig sein, ohne auf Mikromanagement zurückzugreifen, wenn ein Projekt schlecht läuft. Ich habe für technische Leiter gearbeitet, die die Dinge so schwarz und weiß sahen (wie das Programmieren), dass sie einfach nicht wussten, wie sie ihre Teams motiviert halten und das Beste aus ihren Kollegen herausholen sollten, was sie während des Prozesses verärgerte.

• Die Kontoverwaltung ist eine nicht technische Fähigkeit, aber eine lebenswichtige. Sehr oft muss ich dem Endkunden den Projektstatus mitteilen, und wenn es mal nicht so läuft, muss ich einen Weg finden, die Situation zu entschärfen, damit der Kunde Kunde bleibt. Dies ist eine völlig nicht technische Fähigkeit und mehr über zwischenmenschliche Fähigkeiten.

• Budgetierung, eine Schlüsselkomponente meiner Rolle besteht darin, sicherzustellen, dass die Gewinnspannen für jedes Projekt, das ich liefern muss, hoch sind. Dies bedeutet, dass Sie eine Tabelle haben, um alle Projektkosten im Auge zu behalten.

Also los geht's, technisch zu sein hilft, aber PM ist viel mehr, als die technischen Einzelheiten eines Projekts in- und auswendig zu kennen. Ein guter PM muss genug technisches Bewusstsein haben, damit die Entwickler keinen Sand über die Augen legen, aber es muss nicht in die Tiefe gehen. Ein talentierter PM wird talentierte Leute finden, die diese Seite des Projekts für ihn erledigen, was mit dem Ressourcenmanagement zusammenhängt. Wenn überhaupt, ist es also wohl viel wichtiger, einen guten Überblick über das Projekt zu haben, von der Stakeholder-Ebene bis hin zu den technischen Einzelheiten des Projekts.

Es ist wahr, dass Entwickler lernen können, PM zu werden, aber nicht jeder Entwickler hat die richtige Persönlichkeit dafür, wie der von mir erwähnte technische Leiter.

Ich habe als PM bei 2 Digitalagenturen gearbeitet, meine Meinung:

• Es hängt davon ab, ob!

Was an? Es hängt von der Agentur selbst ab und ob Sie tatsächlich jemanden anderen als einen Account Manager und Entwicklungsleiter brauchen, der eine Rolle bei dem Projekt spielt.

Manchmal hatte ich das Gefühl, dass meine Rolle unnötig war – und manchmal hatte ich das Gefühl, dass das Projekt auseinanderfallen würde, wenn ich es nicht zusammenhalten würde.

Worauf es ankommt, ist Arbeitsteilung. Gibt es eigentliche Arbeit für den PM? Oder ist er/sie nur da, weil jemand in der Geschäftsführung es aus welchen Gründen auch immer für notwendig hielt, einen Projektleiter im Team zu haben?

Manchmal gibt es nur einen Weg, das herauszufinden. Warum nicht versuchen, ein Projekt ohne PM zu starten, und sehen, wie es läuft? Finden Sie heraus, welche Aufgaben versäumt werden, was nicht kommuniziert wird und so weiter. Wenn Sie feststellen, dass die Dinge ohne diese zusätzliche Person im Mix reibungslos laufen, besteht die Möglichkeit, dass ihre Stelle in Ihrem Unternehmen überflüssig ist. Wenn alles schief geht (und es eilig hat), dann wissen Sie, dass dieses Teammitglied eine Schlüsselrolle gespielt hat, auch wenn es zunächst nicht offensichtlich war.

Gute PMs machen ihre Teams besser, finden Probleme und lösen sie proaktiv, sodass niemand jemals weiß, dass ein potenzielles Problem vermieden wurde. Anders ausgedrückt: Wenn Sie einen großartigen PM haben, wissen Sie manchmal nicht einmal, dass er/sie da ist. Der Job selbst soll nicht auffällig sein. Stattdessen sollen sie für einen reibungslosen Ablauf sorgen und aus dem Weg gehen, damit jeder seine Arbeit so effizient wie möglich erledigen kann, und das Projekt um Hindernisse herum navigieren, bevor jemand anderes sie bemerkt. Es ist, als wären sie der Kapitän eines Schiffes, das um Eisberge herumnavigiert, während alle darauf achten, dass der Motor richtig läuft. Nur weil Sie nicht all die Arbeit sehen, die sie leisten, heißt das nicht, dass sie keine Schlüsselrolle spielen.

Wenn ich mir die Liste der Symptome anschaue, würde ich sagen:

• Nein.

• Schlechte PMs sind überflüssig (zumindest in dem Sinne, dass Sie sie loswerden könnten, ohne viel zu verlieren).

• Entwickler, die ein Talent dafür zeigen, können zwar PMs werden, aber dies sollte formal anerkannt und unterstützt werden (und aus mehr bestehen als "Ich mache meine eigenen Zeitpläne")