Ein paar verwandte Probleme:
Unnötig zu sagen, dass wir bei Projekten mit diesem Sponsor mit erheblichen Problemen enden, hauptsächlich einem Mangel an definierten Plänen, Umfangszunahme und sich ändernden Anforderungen. Ich glaube ehrlich gesagt nicht, dass dieser Sponsor den Wert eines PM versteht oder schätzt, aber abgesehen von der langfristigen Aufgabe, ihn darüber aufzuklären, gibt es Möglichkeiten, die Probleme, die diese Eigenschaften auf kürzere Sicht verursachen, zu mindern?
Ein Werkzeug, das ich in verschiedenen Kontexten verwende, ist die Abrechnung der Arbeit, die sie zwischen wertschöpfender und verschwendeter Arbeit aufteilt (oder nicht wertschöpfend; vielleicht ziehen Sie es vor, diesen Namen zu verwenden, da er nicht so hart klingt). Die Definition von Verschwendung unterscheidet sich zwischen den Teams, aber definitiv ist die gesamte Nacharbeit nicht wertschöpfend. Wenn Sie "viel unnötige Arbeit" sagen, frage ich: Wie viel genau? Wenn Sie die Daten bereitstellen können, ist dies ein guter Ausgangspunkt für eine Diskussion mit Ihren Stakeholdern. Es ist viel schwieriger, mit Fakten zu diskutieren als mit Meinungen.
Ich würde es mit allen Situationen untermauern, die Sie auf jedes von Ihnen erwähnte spezifische Problem ansprechen können:
Wenn Sie Wert-/Verschwendungsdaten gesammelt haben, sollten Sie auch in der Lage sein, zu zeigen, wie viel solche "Praktiken" die Organisation kosten. Gleichzeitig kostet es fast nichts, einige von ihnen zu reparieren, z. B. die Leute auf dem Laufenden zu halten.
Eine andere Strategie, um mit einer solchen Situation umzugehen, könnte darin bestehen, der Haltung „es ist besser, um Vergebung zu bitten als um Erlaubnis“ zu folgen. Vor allem, wenn Sie an Dinge denken, die Sie im Team tun, wie z. B. die Planung. Wenn Sie den Druck ertragen können, sofort zu beginnen und das zu tun, was Sie für richtig halten (Planung), tun Sie es einfach. Sie gehen Risiken ein, aber es kommt wirklich selten vor, dass Menschen dafür verantwortlich gemacht werden, dass sie gute Arbeit leisten.
Und schließlich ist es möglich, dass sich VP nicht ändert, egal was Sie tun. Dann ist es Ihre Entscheidung: Entweder Sie akzeptieren die Tatsache oder Sie verlassen die Organisation. Wenn Sie sich dafür entscheiden, dort zu bleiben, müssen Sie natürlich viel Schadensminderung tun, z. B. indem Sie das Team so weit wie möglich von zufälligen Entscheidungen isolieren oder versuchen, eine Arbeitsorganisation einzuführen, die solche Dinge absorbiert (kleine Arbeitspakete, enge Feedbackschleifen). .
Ein paar Dinge, die ich ausprobiert habe, mit unterschiedlichem Erfolg (aber alles sicherlich besser als nichts:
Bei solchen Themen greife ich gerne in meinen agilen Werkzeugkasten und entstaube mein persönliches Schlagwort: „Keine unsichtbare Arbeit – niemals !“ Schauen wir uns an, wie dies in einem agilen Kontext hilft.
Mein Sponsor ist visionär, kommuniziert die Vision aber nicht klar genug, um eine Umsetzung zu ermöglichen. Dies führt zu vielen unnötigen Nacharbeiten.
Kein Problem! Der Sponsor ist allein verantwortlich für den Erfolg (oder Misserfolg) des Projekts. Sie können dem Sponsor helfen, das Projekt letztendlich zum Erfolg zu führen, indem Sie sicherstellen, dass alle Nacharbeiten als Arbeit dokumentiert werden . „Rework“ erhält keine Sonderbehandlung; Wenn es sich um eine Aufgabe handelt, die Zeit, Geld oder Projektressourcen verbraucht, dokumentieren Sie sie einfach und fügen Sie sie dem Backlog hinzu. Der Product Owner muss dann die neuen Arbeitselemente priorisieren und dadurch vielleicht andere User Stories im Backlog verschieben, und das Team wird die neue Arbeit aus der Warteschlange nehmen, wenn sie den Anfang (oben?) des Backlogs erreicht und erreicht hat bereit, in den nächsten Sprint gezogen zu werden.
Dies führt schließlich zu Fragen wie "Warum verschiebt sich der Liefertermin des Projekts in die Zukunft?" Das ist gut und ermöglicht es Ihnen, eine Diskussion über den Prozess zu führen.
Wenn der Prozess für den Sponsor funktioniert, ist der Prozess in Ordnung. Selbst wenn der Prozess suboptimal ist, darf der Sponsor beide Teile behalten, wenn der Sponsor den Prozess unterbricht.
Mein Sponsor kommuniziert direkt mit Teamleitern, ohne mich (oder andere Mitglieder des Projektteams) auf dem Laufenden zu halten. Das hält mich davon ab, Veränderungen kontrolliert zu managen, es ist schwer, einfach Schritt zu halten.
Ihre Teamleiter handhaben Veränderungen. Das ist klasse! Da sie bereits vom Sponsor delegiert werden, müssen Sie ihnen lediglich die zusätzliche Verantwortung übertragen, das Backlog mit allen neuen Arbeiten zu aktualisieren.
Wenn der Sponsor mit Joe spricht und vorschlägt, dem Projekt eine Embiggening-Funktion hinzuzufügen, dann ist Joe dafür verantwortlich, die neue User Story zum Backlog hinzuzufügen. Wenn Joe diese Verantwortung nicht will, muss er den Sponsor an den Product Owner oder Scrum Master verweisen. Joe darf jedoch nicht das gesamte Team verpflichten oder Zeit mit „unsichtbarer Arbeit“ verbringen. Die Arbeit muss als Arbeit an das Team übermittelt und sichtbar zur Arbeitswarteschlange hinzugefügt werden.
Betrachten Sie es so: Der Prozess wird nur umgangen, weil es weder für Joe noch für den Sponsor einen klaren Vorteil gibt, ihn zu befolgen. Wenn Joe oder der Sponsor erkennen, dass ein Endlauf um den Prozess mehr Arbeit für sie persönlich bedeutet, dann haben sie einen Anreiz, den Prozess effizient zu gestalten. Wenn der Prozess andererseits keinen Wert bietet, sollten Sie den Prozess so lange ändern, bis dies der Fall ist. Das ist ein Gewinn/Gewinn für alle!
Mein Sponsor ist ein VP, der ehrlich davon überzeugt ist, dass einige Aspekte eines erfolgreichen Projekts (z. B. ein durchgängig begründeter Business Case) ihn etwas angeht und niemanden sonst.
Genial! Da Ihr VP einen Geschäftsbedarf identifiziert hat, sollte er gerne Teamressourcen für die Aufgabe zuweisen. Das bedeutet, dass die Zeit, die für das Sammeln von Daten für Anwendungsfälle, das Schreiben von Vorschlägen und Spezifikationen und andere damit zusammenhängende Aufgaben aufgewendet wird, dem Backlog hinzugefügt werden sollte.
Wenn es Arbeit ist, die der VP erledigen möchte, dann fügen Sie ihn auf jeden Fall dem Team hinzu und lassen Sie ihn User Stories aus dem Backlog in jeden Sprint ziehen. Wenn es Arbeit ist, die der VP delegieren möchte, zieht das Team die Aufgaben in einen Sprint, wenn:
Da es die Aufgabe des Product Owners ist, das Backlog zu priorisieren, ist es Ihre Aufgabe, den VP an den Product Owner zu verweisen, wenn es ein Problem mit der Priorisierung der Arbeit gibt. Wenn der Product Owner zustimmt, dass die Aktualisierung eines Business Case in diesem Sprint wichtiger ist als die Embiggening-Funktion des Sponsors, dann ist dies eine wertbasierte Entscheidung für das Unternehmen. Alle gewinnen!
Mein Sponsor ist der (allzu häufige) Typ, der möchte, dass die Arbeit an einer Lösung beginnt, bevor ein angemessener Plan (oder sogar eine Definition, wie die Lösung aussehen wird) vorhanden ist.
Wunderbar! Arbeit um ihrer selbst willen kann sehr lohnend sein. Wenn es sich um unsichtbare Arbeit handelt, wird natürlich niemand dafür gewürdigt, und niemand muss mit Konsequenzen rechnen, wenn er nicht einmal das Minimum plant oder entwirft, das agile Prozesse zum Erfolg benötigen.
Die Lösung ist wie bisher: Alle Arbeiten dokumentieren. Eine neue Architektur bauen, weil die Lösung vom letzten Monat nicht gut durchdacht war? Fügen Sie es als sichtbare Arbeit hinzu. Die unkluge Embiggening-Funktion hat den Tod von Millionen Ihrer besten Kunden verursacht? Fügen Sie Ihrem Projektbudget die Kosten für Rechtsstreitigkeiten, Identitätswechsel und Umzug in ein anderes Land hinzu.
Unabhängig vom Ergebnis, ob gut oder schlecht, muss der Prozess sichtbare Konsequenzen für die gesamte Organisation haben. Ein guter Prozess wird netto positive natürliche Folgen haben; ein schlechter wird für alle Beteiligten deutlich weniger schön sein. Alles beginnt jedoch damit, Arbeit sichtbar zu machen .
Fügen Sie einige sinnvolle Inspektions- und Anpassungspunkte hinzu, wie z. B. zweiwöchentliche Sprint-Reviews und Retrospektiven, und Sie werden vielleicht feststellen, dass „Eintauchen“ eine Strategie ist, die für Ihr Unternehmen funktioniert. Eine kleine Just-in-Time-Planung kann sehr effektiv sein.
„Measure once, cut once“ ist der Inbegriff von Agilität. Sie könnten sogar die meiste Zeit mit "einmal schneiden, einmal messen" davonkommen. Allerdings ist "zweimal schneiden, nie messen" einfach albern.
Die meisten meiner Antworten stammen aus einer agilen Perspektive, aber letztendlich können Sie dasselbe mit jeder Methodik tun. Machen Sie die Arbeit einfach sichtbar!
Am Ende ist ein guter Projektmanager der Hirte des Projektprozesses , nicht das Aushängeschild für seinen endgültigen Erfolg oder Misserfolg. Ihre Hauptaufgabe besteht darin, die Organisation – einschließlich des Sponsors des Projekts! – über den aktuellen Prozess aufzuklären und den Leuten zu helfen, den Prozess so anzupassen (oder neue zu implementieren), dass sie ihre Arbeit erledigen können.
Schützen Sie das Team. Management erziehen. Tun Sie, was immer Sie tun müssen ... aber niemals unsichtbare Arbeit !
Dokument, Dokument, Dokument.
Die einzige Möglichkeit, diese Art von Sponsor zu überleben, besteht darin, ALLES zu dokumentieren und dann alles zu verfolgen.
Vermutlich haben Sie einen ursprünglichen Umfang, ein Budget und einen Zeitplan oder eine Reihe von Anforderungen. Beginnen Sie damit, den Verbrauch des Budgets zu verfolgen und aufzuzeigen, wo aufgrund von Nacharbeit, Fehlkommunikation, unklarer Richtung usw. mehr aufgebraucht wird. Sie haben recht damit, dass er den Wert einer PM nicht versteht, aber es gibt Möglichkeiten, subtil vorzugehen ihn erziehen. Zeigen Sie ihm, wo Überschreitungen sind oder wo Sie während des gesamten Projekts Geld hätten sparen können (und ihn folglich gut aussehen lassen).
Und stellen Sie sicher, dass Ihr Team versteht, wie das Management eines Projekts funktioniert, damit es versteht, wie wichtig es ist, dass es über Gespräche mit dem Sponsor informiert wird. Du kannst ihn nicht davon abhalten, mit ihnen zu sprechen, aber du kannst sie dazu bringen, dich wissen zu lassen, wenn er es tut.
Viel Glück.