Projektmanagement Softwareentwicklung

Softwareentwicklung fĂŒr Projektleiter, Manager und Entwickler

IT-Projektmanagement RSS
  • Projektleiter exponiert oder als Teammitglied

    Peter Rohde

    Es ist eine lange anhaltende Diskussion ĂŒber die Position und die inhaltliche AusprĂ€gung eines Projektleiters. In den letzten Jahren hat sich zwar immer weiter die grundlegende Ausbildung zu einem Projektleiter durchgesetzt, in den Punkten – wie involviert ein Projektleiter in die Projektarbeit ist und inwieweit er die SchlĂŒsselposition fĂŒr Entscheidungen hat – gibt es allerdings noch eine große Bandbreite.

    Solange ein Projekt sich in dem gewĂŒnschten oder geduldeten Rahmen bewegt gibt es ja auch – scheinbar – keinen Bedarf ĂŒber den Projektablauf nachzudenken.
    Erst wenn die Situation unangenehm meist sogar erst wenn es sehr unangenehm wird, erfolgt ein Review der Situation. Das Review hat in vielen FĂ€llen als Ergebnis neue bzw. erweiterte bĂŒrokratische VerĂ€nderungen sowie die “klare” Schulderkennung.

    Ausgehend davon, dass jeder aus dem Team sein Bestes fĂŒr das Projekt eingegeben hat, sehen die Review-Ergebnisse hĂ€ufig so aus, als ob niemand es glaubt. Es werden Schuldfragen aufgeworfen und versuchsweise geklĂ€rt sowie einfache bĂŒrokratische Mittel eingebracht, um das Projekt wieder in den Plan zu bringen.
    Die eigentliche Frage – an welcher Stelle die verschiedenen Sichtweisen der Projektteilnehmer auseinander gehen, ohne dass es offensichtlich wurde – wird meist noch nicht einmal gestellt. Die “Verklettung” der Projektteilnehmer kann nicht offensichtlich werden.

    Der Projektleiter bringt die neuen Direktiven ins Projekt und bei einem fortschrittlichen Projekt werden diese auch von allen Teilnehmern – meist in einem Meeting – akzeptiert und das Projekt weitergefĂŒhrt.

    In vielen FĂ€llen funktioniert diese Strategie – wenn man sich damit arrangiert, dass das Projekt erheblich teurer oder das Ergebnis erheblich anders wird.

    Der Projektleiter ist “Master and Commander” und bleibt es nach der Krise auch bzw. wird durch einen neuen ersetzt.
    In einigen Projektmodellen – wie bei Scrum – wird schon versucht, das Projekt auf eine andere Entscheidungs- und Verantwortungsbasis zu heben. Das Team entscheidet, wie und in welcher Zeit eine Aufgabe gelöst wird und ĂŒbernimmt damit auch die Verantwortung fĂŒr die Umsetzung.
    Scrum ist nur fĂŒr kleine Projekte geeignet – außerdem ist ein bĂŒrokratisches Modell, wie auch dieses, immer nur eine KrĂŒcke, ein Mindestmaß an Sicherheit und DurchgĂ€ngigkeit zu liefern.

    Qualitativ hochwertige bzw. anspruchsvolle grĂ¶ĂŸere Projekte bedĂŒrfen bei einer guten DurchfĂŒhrung, Mitarbeiter, die bewusst oder unbewusst einen sehr guten Informationstransfer pflegen sowie eine menschlich offene Gruppenstruktur haben. Es muss in diesen Projekten möglich sein, dass jeder Informationszuwachs aus der Gruppe offen entgegengenommen werden kann. Die Hierarchie-Strukturen behindern dort nur – ein Projektleiter ist somit “nur” noch ein Teammitglied mit organisatorischen Aufgaben – wie dem Informationstransfer in die GeschĂ€ftsfĂŒhrung.
    Dieses Vorgehen wĂ€re innovativ und bedarf einer stĂŒtzenden Struktur fĂŒr Kommunikation und Persönlichkeitsentwicklung.

    Die Mitarbeiter sowie der Projektleiter eines solchen Teams sind bereit, sich von ihrer “EinzelkĂ€mpfer” Art zu lösen und den sozialen Kontext eines Teams als Bereicherung zu erfahren.
    Im Gegenzug ist es notwendig, dass die Leitung eines Unternehmens im Team den Erfolgsbringer sieht und FĂŒhrung als eine Teilaufgabe im Team.
    Nicht der, der oben auf dem Treppchen steht ist der Gewinner – sondern alle die, die die Position ermöglicht haben.

    No Comments

Leave a Reply