Kategorien
Sehr geehrter Herr Projektleiter …
Den Artikel heute kann man wohl als eine Art offenen Brief an alle Projektmanager betrachten, denn in meinen zehn Jahren Projekterfahrung (oh mein Gott bin ich alt) haben rund die hälfte der eingesetzte Projektleiter ein und den selben Fehler gemahct und damit sozusagen das Projekt vergiftet.
Eigentlich ist es in einem Satz gesagt: „Sehr geehrter Projektleiter, bitte sage uns am Anfang des Projektes, was deine Aufgabe ist„. Kennt ihr das nicht? Ein Projektleiter wird eingesetzt, ihr seit die ihm unterstellten Entwickler und programmiert den ganzen Tag und vom Projektleiter ist nie was zu sehen? Was macht dieser (gefühlt) unheimlich gut verdienende Mensch denn den ganzen Tag? Uns unterstützen jedenfalls nicht? Und wenn er uns nicht direkt hilft, dann kann er ja auch eigentlich für niemanden nützlich sein, denn wir sind ja schließlich das Team.
Ich habe mich schon öfters mit diesen Gedanken erwischt, aber wenn man mal ganz ehrlich ist, so gibt es noch sehr viele administrative Dinge, die man übernehmen kann. Dinge, von denen das Team nichts mitbekommen muss, sowas wie mit dem Lenkungsausschuss reden oder Urlaube koordinieren, Mitarbeiter suchen und und und. Das Problem ist nur, dass hier häufig die Transparenz fehlt. Dabei kann es doch so einfach sein. Definieren wir genau was die Aufgaben des PL sind, so müssen wir uns nicht mehr auf ein komisches Bauchgefühl verlassen, nein wir können direkt prüfen, ob er seine Aufgaben erfüllt und ob es sich mit dem deckt, was wir gerne haben würden.
In offenen Projektkulturen kann man auch gemeinsam die Rolle des Projektleiters ausschmücken, was mir persönlich am besten gefällt. Unser Teamleiter hat dies zum Beispiel so gemacht und bis jetzt ist dies auch mein bester Teamleiter den ich hatte. Also noch mal kurz: Definiert eure Aufgaben, dann gibt es keine Missverständnisse darüber, ob ihr nützlich seid oder nicht.
Ich bin eigentlich nach wie vor der Meinung, dass ein PM sozusagen der Übersetzer für Kunde/Fachlichkeit ist .. Der Techniker ist dann der Übersetzer von Fachlichkeit/Technik. D.h. der PM macht die Anforderungsanalyse und sorgt dafür, dass ein Techniker saubere fachliche Anforderungen bekommt (zumindest die nicht technisch motivierten Anforderungen). Der PM ist ja schließlich „vom Fach“. Ansonsten kann er ja auch PM in einer Bäckerei sein. Natürlich sind auch die Techniker Stakeholder und können und sollen in die Prozesse einbezogen werden – in der Praxis ist es aber leider erfahrungsgemäß so, dass die Technik die Kundenwünsche ungefiltert auf den Tisch bekommt.
Durch Scrum muss ich erhlich sagen, bin ich total gegen die klassische Rolle des Projektleiters. Das fängt schon damit an, dass die Entwickler ihm unterstellt sind, wobei die Entwickler am besten Wissen, wie etwas umgesetzt werden kann. Oftmals beteiligen sich die Projektleiter garnicht an der Umsetzung, bestimmen aber, wie etwas gemacht werden muss … Finde ich ja sehr wiedersprüchlich 😉
Andererseits muss man auch erstmal damit klarkommen, dass bei einem Wechsel vom Projektleiter zum Product Owner dieser nicht mehr die Entscheidungsgewalt hat, wie etwas gemacht werden muss, sondern nur noch dass es gemacht werden muss. Ich denke, das ist eine der größten Hürden bei Scrum, denn die Führungsrolle des Projektleiters schwindet erst einmal dahin. Der Scrum Master übernimmt die laterale Führung und das DevTeam selbst überlegt sich, was für Personal sie noch brauchen 😉
Als Entwickler interessiert mich eigentlich garnicht, was der Projektleiter tut, ich bezahle ihn nicht und wenn was nicht klappt ist er schuld und nicht ich. Konzentriere mich eher auf meinen Teil….
@Zabus: Das geht so lange gut, bis du Hilfe benötigst bei einem Punkt, bei dem du glaubst, dass es die Aufgabe des PL ist.
Die Hauptaufgabe des PL soll sein das Team von möglichst vielen Blödheiten die von „Oben“ kommen zu schützen. Und falls das Team mal scheisse baut vor den „Oberen“ den Kopf hinzuhalten.
Auch deshalb wurde Scrum „erfunden“ und genau deshalb werden wir es in den nächsten Wochen, gegen alle widrigen Umstände und Skepsis, in dem jetzigen Unternehmen einführen.
Bereits die ersten User Story Workshops und Sprint Plannings, obwohl sie nur Schnupperkurse waren, erzeugte die Diskussionen, Transparenz und Zusammenarbeit, die große Projekte mit schwammigen Anforderungen benötigen.
Schon das Aufschrecken mancher, bisher „klassischen“ Projektleiter, über die Fülle an Dingen, die sonst untergegeangen oder der freiene Interpretation des Teams zum Opfer gefallen und evtl. damit vor dem Kunden gescheitert wären, war das Geld wert.