project management



  • was muss ein projectleiter wissen? Z.B. V-Modell, waterfall-modell, was noch?



  • Wie man Miarbeiter motiviert und überhaupt mit Menschen umgeht.
    Wie man Fähigkeiten der Leute rausfindet/einschätzt und sie dementsprechend mit Arbeit versorgt.
    Wie man Aufwand schätzt und ggf. Maßnahmen ergreift wenn das Ziel zu scheitern droht.


  • Mod

    Wie man die Leute identifiziert, die kein Interesse am Erfolg des Projekts haben (die gibt's immer). [Das kann z.B. jemand sein, dessen Job durch die neue Software beseitigt oder beeinträchtigt wird. Oder ein anderer Abteilungsleiter, der gerne Nachfolger von Deinem Auftraggeber würde, aber dazu warten muß, bis Dein Auftraggeber auf die Schnauze fällt - z.B. mit einem größeren Softwareprojekt.]

    Kommunikation, Kommunikation, Kommunikation.

    Du mußt die Wehwehchen und Schwächen der Leute aus dem Projektteam kennen, um zu wissen, wofür sie einsetzbar sind und wofür nicht.

    Weiterhin Entscheidungen bei unklarer Informationslage treffen (d.h. nicht alles ist bekannt, trotzdem mußt Du anfangen).

    Mut, unangenehme Dinge den Auftraggebern zu sagen.

    Du mußt ein Projekt in so kleine Portionen zerlegen können, daß diese bearbeitbar werden und man nicht daran verzweifelt. ["Wie ißt man 3 Kilo Hackfleisch?" "Langsam."]

    Von den formalen Tools, die in den PM-Büchern stehen, ist meines Erachtens am wichtigsten die Kostenkontrolle und die Kostenvorhersage. Wenn Dir das Geld ausgeht, ist Dein Projekt auf jeden Fall am Ende, egal wie gut oder schlecht es lief.

    Ich behaupte mal, daß jemand mit Kenntnissen des V-Modells, aber ohne obige Kenntnisse (und die Nennungen von estartu) ein Projekt sauber an die Wand fährt, aber jemand mit entsprechenden Kenntnissen auch ohne V-Modell das Projekt hinbekommen würde.

    Btw, V-Modell oder Wasserfallmodell sind bestenfalls Ideen, wie man ein Projekt bearbeiten könnte - bei größeren Projekten zersplittert sich das Gesamtprojekt in zahlreiche kleine Wasserfälle, es ist nicht mehr möglich, das Projekt mit einer breiten globalen Linie zu fahren. D.h. der Gedanke "jetzt spezifizieren alle" "jetzt programmieren alle" etc funktioniert nicht. Einige müssen schon anfangen, während andere noch spezifizieren, aus Zeitgründen. Dummerweise benötigen die Leute, die anfangen, aber eigentlich auch Informationen von den Leuten, die noch spezifizieren. Sowas dann offen zu strukturieren und später die fehlenden Stücke einzupassen ist die eigentliche Schwierigkeit.



  • netrobot schrieb:

    was muss ein projectleiter wissen? Z.B. V-Modell, waterfall-modell, was noch?

    Entweder: "Was muss ein Projektleiter Wissen? Z. B. V-Modell, Wasserfallmodell; Was noch?"
    Oder: "Was muss ein Projectleader wissen? Z. B. V-Model, Waterfall-model; Was noch?"

    Aber das was du da geschrieben hast, das führt ja zu Augenkrebs.

    Die Antwort auf die Frage haben estartu und Marc++us schon gegeben.



  • Marc++us schrieb:

    Wie man die Leute identifiziert, die kein Interesse am Erfolg des Projekts haben (die gibt's immer). [Das kann z.B. jemand sein, dessen Job durch die neue Software beseitigt oder beeinträchtigt wird. Oder ein anderer Abteilungsleiter, der gerne Nachfolger von Deinem Auftraggeber würde, aber dazu warten muß, bis Dein Auftraggeber auf die Schnauze fällt - z.B. mit einem größeren Softwareprojekt.]

    Wie entschärfst du solche Leute? Oft kann man die ja nicht einfach aus dem Projekt hauen.


  • Mod

    Wie jeden Menschen: Halte ihm eine größere Wurst vor den Mund. Ob die aus Plastik oder echt ist, erkennen die erst wenn dein Projekt erfolgreich war.

    MfG SideWinder


  • Mod

    rüdiger schrieb:

    Marc++us schrieb:

    Wie man die Leute identifiziert, die kein Interesse am Erfolg des Projekts haben (die gibt's immer). [Das kann z.B. jemand sein, dessen Job durch die neue Software beseitigt oder beeinträchtigt wird. Oder ein anderer Abteilungsleiter, der gerne Nachfolger von Deinem Auftraggeber würde, aber dazu warten muß, bis Dein Auftraggeber auf die Schnauze fällt - z.B. mit einem größeren Softwareprojekt.]

    Wie entschärfst du solche Leute? Oft kann man die ja nicht einfach aus dem Projekt hauen.

    Ein Maßnahmenpaket...

    - Blenden, täuschen, irreführen, ablenken
    - ignorieren
    - ihnen zuarbeiten
    - (mächtigere) Verbündete gegen sie suchen
    - sie vom Gegenteil überzeugen
    - Projekt abbrechen

    Je nachdem. Kann man nicht pauschal sagen.

    Ein unwilliger Vorarbeiter ist kein großes Problem, ein unwilliger Werksleiter schon.


Anmelden zum Antworten