Wie kann ich unerfahrene Teammitglieder dazu bringen, Projekttermine einzuhalten?

TL;DR

Ziele und Schätzungen sind zwei verschiedene Dinge. Sie verwechseln die beiden und bereiten Ihr Team auf einen Misserfolg vor.

Ziele vs. Schätzungen

Ein Ziel ist etwas, das Sie Ihrem Team zuweisen, z. B. „Ich möchte, dass diese Aufgaben in einem Monat erledigt sind.“ Managementziele sind soweit in Ordnung, aber sie bieten selten ein Mittel, um dorthin zu gelangen. Für die eigentliche Bewältigung der Aufgaben müssen Sie sich auf das Wissen, die Fähigkeiten und die Erfahrung Ihres Teams verlassen.

Schätzungen hingegen sind das, was Ihr Team auf der Grundlage seines aktuellen Verständnisses des Problembereichs und seiner Einschätzung seiner eigenen Fähigkeiten bereitstellt. Eine erfahrene Person kann möglicherweise schneller eine Funktion hinzufügen oder ein Problem lösen als jemand mit weniger Erfahrung. Andererseits führt die Erfahrung manchmal zu Einsichten darüber, wie scheinbar einfache Aufgaben länger dauern können als erwartet. In jedem Fall sind die Schätzungen im Allgemeinen gute Richtlinien dafür, wie lange die tatsächlichen Ausführenden der Aufgabe denken, dass der Job dauern wird.

Im Moment schätzt Ihr Team, dass das Projekt drei bis fünf Monate dauern wird, während Ihr Managementziel einen Monat oder weniger beträgt. Keine Seite ist notwendigerweise falsch; Es besteht jedoch eindeutig eine Diskrepanz zwischen Zielen und Schätzungen, die behoben werden muss.

Lösung der Differenzen durch Dialog

Wie kann ich Teammitgliedern helfen, Projekte innerhalb der Zeit fertigzustellen?

Das ist die falsche Frage. Was Sie wirklich fragen, ist, wie Sie Ihr Team dazu bringen können, das zu liefern, was Sie wollen, wann Sie es wollen, anstatt wenn sie glauben, dass sie es Ihnen geben können.

Wenn Sie wissen, wie Sie Aufgaben schneller erledigen können, teilen Sie Ihr Wissen. Dies wird wahrscheinlich bedeuten, dass Sie ein praktischer Teilnehmer im Team sind. Möglicherweise müssen Sie sogar verschiedene Aufgaben selbst übernehmen, da Sie Dinge möglicherweise schneller erledigen können als die anderen Teammitglieder.

Dann wieder vielleicht nicht. Vielleicht hat das Team Recht mit der Tatsache, dass es mit den vorhandenen Ressourcen und der Erfahrung des Teams länger dauern wird, als Sie möchten, bis das Team die Meilensteine ​​​​des Projekts erreicht. In diesem Fall sollten Sie sorgfältig prüfen, ob Ihr Team richtig liegt, es sei denn, Sie planen, die gesamte Arbeit selbst zu erledigen, und haben dies in Ihre Planungsschätzungen einbezogen.

Wenn die Leitung eines Projekts nicht mit den Teammitgliedern Schritt hält, arbeitet ein guter Projektmanager mit den Beteiligten und den Teammitgliedern zusammen, um zu verstehen, warum . Vielleicht fehlt es Ihrem Team einfach an Selbstvertrauen oder Sie möchten einen Puffer, damit sie nicht beschuldigt werden, wenn die Dinge in Verzug geraten. Oder vielleicht sind die Liefertermine des Projekts aufgrund der Fähigkeiten des Teams oder der für das Projekt verfügbaren Ressourcen unangemessen. Was auch immer der Grund ist, Sie werden der Sache nicht wirklich auf den Grund gehen, bis es ein ehrliches Gespräch zwischen dem Management und dem Rest des Teams über die Probleme und Risiken gibt.

Die Geschäftsleitung ist verantwortlich

Kürzlich haben wir eine Menge Leute eingestellt, die sagen, dass sie wenig Erfahrung mit Technologie haben. (sieh)

Folgendes berücksichtigen:

• Die Manager, die Mitarbeiter eingestellt haben, die möglicherweise nicht für die Arbeit qualifiziert sind, liegen in der Verantwortung des Managements.
• Die Einstellung von Mitarbeitern, die zwar qualifiziert sind, denen es aber an Selbstvertrauen mangelt – etwas, das sich in jedem vernünftigen Vorstellungsgespräch hätte zeigen sollen – liegt in der Verantwortung des Managements.
• Das Versprechen von Fristen gegenüber einem Kunden vor dem Einholen genauer Schätzungen von den Aufgabenträgern liegt in der Verantwortung des Managements.
• Die Organisationskultur festzulegen, die das Projektteam auf einen Todesmarsch vorbereitet, liegt in der Verantwortung des Managements.

Ganz gleich, wie man es betrachtet, Menschen können nur Verantwortung für Aufgaben übernehmen, zu deren Erledigung sie sich bereit erklärt haben, und zwar in voller Kenntnis der Details und Umstände. Sie können den Mitgliedern eines Projektteams sicherlich Aufgaben und Fristen zuweisen und sie dann für die Managementziele „zur Rechenschaft ziehen“, aber das funktioniert in der realen Welt selten gut. Vielleicht bekommen Sie sogar Teammitglieder, die allem zustimmen, anstatt ihren Job zu verlieren; Das wird Ihnen viel Zustimmung bringen, aber selten werden Sie fertige Ergebnisse erhalten, wenn Sie sie erwarten.

Das Management ist dafür verantwortlich, genaue Schätzungen zu sammeln, die Erwartungen des Kunden zu verwalten und das Team auf jede erdenkliche Weise zu befähigen, damit das Team so gut wie möglich arbeiten kann, wo es ist und mit dem, was es hat. Die Nichterfüllung dieser wesentlichen Managementaufgaben führt dazu, dass 68 % der Projekte scheitern .

Sichtbarkeit und Transparenz machen mittelmäßige Teams effektiver

Ihre Mitarbeiter auszupeitschen, bis sich die Moral verbessert, funktioniert selten. Wenn Sie jedoch Ihren Projektmanagementprozess in einen Rahmen umwandeln, der auf schnelle Feedbackzyklen, Prozesstransparenz und vollständige Transparenz der Projektprozesse und -hindernisse Wert legt, wird Folgendes sichergestellt:

1. Das Team ist aktiv in den Prozess eingebunden und verfügt über einen Mechanismus zur Kommunikation über Prozesshindernisse und Ressourcenlücken an Manager, die befugt sind, etwas dagegen zu unternehmen.
2. Das Managementteam hat zu jedem Zeitpunkt der Zeitachse einen vollständigen Überblick über den Fortschritt des Projekts.
3. Risiken für das Projekt werden sichtbar (und hoffentlich selbsterklärend), wenn sie vom Team angetroffen werden, wodurch das Management befähigt wird, diese Risiken zu beseitigen oder zu mindern.
4. Mehr Wissen zwischen Team und Management sollte zu genaueren Schätzungen des Teams führen und mehr Wissen in die Hände des Managements legen, um fundierte strategische Entscheidungen für das Projekt zu treffen.

Wenn Sie all dies zusammenfügen, ist es eine effektive wechselseitige Kommunikation , die es Ihrem Projekt ermöglichen kann, trotz seiner Mängel erfolgreich zu sein. Teams, die effektiv kommunizieren, sind häufiger erfolgreich, und wenn sie scheitern, scheitern sie früher und zu geringeren Kosten für das Unternehmen. Fördern Sie eine ehrliche Kommunikation auf allen am Projekt beteiligten Ebenen; Es ist wirklich Ihr bestes Werkzeug, also können Sie es auch so effektiv wie möglich einsetzen.

Sie geben unrealistische Zeitpläne von etwa 3-5 Monaten an

Sie geben realistische Zeitpläne an und berücksichtigen dabei ihre eigenen Fähigkeiten und Erfahrungen. Ihre Erwartungen sind jedoch unrealistisch.

Laut PMBOK gibt es zwei Hauptoptionen der "Schedule Compression":

• abstürzen: Stellen Sie verschiedene Leute ein, geben Sie ihnen Schulungen usw.
• Fast Tracking: Dinge parallel erledigen

Siehe zum Beispiel diesen Blogbeitrag .

Vieles in Ihrem Entwurf deutet darauf hin, dass Ihnen selbst einige grundlegende Grundlagen oder ein Verständnis dafür fehlen, wie Schätzung, Zielvorgabe, Leistung und Risiko funktionieren.

CodeGnome hat in diesem Bereich einiges angesprochen, das Sie genau lesen und versuchen müssen, es zu verstehen. Die einzige Meinungsverschiedenheit, die ich hätte, ist seine Erklärung von Ziel versus Schätzung, bei der ich vorschlagen würde, dass eine Schätzung eine Reihe von probabilistischen Ergebnissen ist und Ihr Ziel deterministisch ist, ein einzelner Wert, den Sie anstreben, auf dem Sie Ihre Kosten basieren, und dagegen an denen Sie Ihre Leistung messen. Es kann zwar von Ihnen zugewiesen werden, aber es ist der Wert, der das Maß an Risiko darstellt, das Sie bereit sind einzugehen, und das irgendwo in der von Ihrem Team bereitgestellten Bandbreite liegt.

Was Ihr Kunde erwartet, ist für den Schätzungsprozess irrelevant und sollte nicht einmal in die Gleichung eingehen. Tatsächlich sollten die Schätzer gegenüber dieser Information blind sein, da Sie nicht möchten, dass ihre Meinungen davon beeinflusst werden. Der Schätzprozess ergibt die Reichweite. Die Geschäftsseite dieses Prozesses wählt das Ziel aus, das mit den Wünschen des Kunden übereinstimmen kann oder nicht. Wenn Ihr Team also drei bis fünf Monate sagt und Sie zwei anstreben, um die Kundenerwartungen zu erfüllen, treffen Sie im Wesentlichen eine Geschäftsentscheidung, das Unternehmen mit Verlust und extremem Ausfallrisiko zu kaufen. Daran ist nichts falsch; Es gibt viele Verlustführer, die sehr profitable Geschäfte auf der ganzen Linie vorantreiben. Aber es ist nicht die Aufgabe Ihres Schätzers, darauf zu kommen.

Schließlich müssen Sie verstehen, wie Leistung funktioniert. Unabhängig vom Ziel sind viele der Ergebnisse, die Sie im Laufe der Zeit sehen werden, sehr, sehr zufällig. Verstehen Sie, was aleatorische Risiken sind und wie sich diese auf die Leistung auswirken. Aleatorische Risiken sind im Gegensatz zu epistemischen Risiken weitgehend oder vollständig nicht reduzierbar. Sie sind zufällig. Sie können sie nicht mildern. Ich erwähne dies, um Ihre Überzeugung in Frage zu stellen, dass ihre Risiken „unrealistisch“ sind. Das impliziert, dass eine Schätzung "realistisch" ist. Sie sollten das Wort „realistisch“ von „Schätzung“ trennen.

Ich stimme CodeGnome zu und möchte weitere hinzufügen

Rückblick

Schauen Sie sich an, was Sie tun und wie Sie das Projekt leiten, und stellen Sie sich eine ehrliche Frage. "Funktioniert es". Ich würde sagen nein ist es nicht. Schauen Sie sich als nächstes Möglichkeiten an, Dinge anders zu machen, indem Sie sich genau ansehen, was Sie tun, lernen Sie dann aus Ihren Fehlern und versuchen Sie, etwas anders zu machen.

Wahnsinn tut immer wieder dasselbe und erwartet ein anderes Ergebnis – Einstein.

Unsicherheit und Komplexität

Als Nächstes müssen Sie zugeben, dass Sie es mit Softwareentwicklung zu tun haben, die, wenn Sie es sich genau ansehen, ein hohes Maß an Unsicherheit in sich birgt. Eventuell mit Anforderungen, Teams, Menschen, Technologien und damit risikobehaftet. So sehr Sie auch planen, Sie werden höchstwahrscheinlich auf Situationen stoßen, die niemand vorhersehen konnte. Schließlich ist Technologie komplex und bewegt sich schnell; Es gibt immer einen hohen Grad an Komplexität in dem, was wir tun.

Lernen Sie, diese Risiken durch empirische Prozesskontrolle statt prozeduraler Prozesskontrolle zu mindern.

Kommunikation

Es scheint, als gäbe es ein gewisses Maß an Missverständnissen in den Anforderungen, Sie denken, es ist ein Monat und das Entwicklerteam denkt, es sind drei ... stellen Sie sich vor ein Whiteboard und besprechen Sie es.

Menschlicher Faktor

Ich wette ziemlich genau, dass Sie und Ihr Team im Moment alle Entscheidungen auf der Grundlage der Fakten treffen, die Ihnen derzeit zur Verfügung stehen. Ich glaube nicht, dass irgendjemand bewusst schlechte Entscheidungen treffen wird. Möglicherweise treffen Sie beide falsch informierte Entscheidungen, da nicht alle Fakten transparent und bekannt sind. Genau in diesem Moment weißt du nicht, was du nicht weißt. In ein paar Tagen werden Sie vielleicht feststellen, dass Ihre Gedanken heute völlig falsch waren.

Hören Sie auf, das Team auf der Grundlage früherer Entscheidungen zu verprügeln , die jeder getroffen hat, und respektieren Sie, dass sie das Richtige tun wollen. Helfen Sie ihnen, das Richtige zu tun, indem Sie ständig kommunizieren und kleinere Korrekturen vornehmen, wenn Sie Abweichungen feststellen (erneut prüfen und anpassen).