Projektstatusbericht - Beispiele und Tipps fürs Projektmanagement gesucht

  • Liebe allwissenden Rab:innen,


    ich hoffe auf euer geballtes Projektmanagement-Wissen und vor allem Erfahrung mit der Praxis!


    Die Vorgeschichte:

    Gerade zurück aus der Elternzeit durfte ich gleich in die interne Leitung eines riesigen Projektes einsteigen. Ich hab die Bewerbung für dieses Projekt damals koordiniert, war auch bei den ersten Bietergesprächen dabei und während meiner Elternzeit haben wir dann den Zuschlag erhalten. Das ganze Projekt ist also schon langsam ins Rollen gekommen, die Projektleitung liegt bei meiner Teamleiterin (PL sowohl nach intern/extern) und meinem Bereichsleiter (PL v.a. nach extern) und es gab einen ersten KickOff Termin, an dem die zig Teams und Abteilungen, die thematisch mit drin hängen, abgeholt und über das Projekt informiert wurden. Eine darüber hinausgehende Struktur oder gar Managementmethode wurde bisher nicht umgesetzt. (Ein Projektstrukturplan wurde angelegt, aber noch nicht vollständig ausgefüllt.) Damit es auch nicht zu langweilig wird, nimmt meine Teamleiterin im nächsten Quartal eine Auszeit und die interne Leitung liegt vermutlich komplett bei mir.


    Ich steh grade vor diesem riesigem, chaotischen Berg und würde es gerne in geordnete Bahnen lenken, die es mir ermöglichen das ganze in 25 Wochenstunden zu koordinieren (neben den anderen Aufgaben, die ich noch so habe). Erste Amtshandlung war die Festlegung regelmäßiger interner Projekttreffen (mit allen, quartalsweise). Als nächstes möchte ich regelmäßige Termine zum Austausch mit den einzelnen Teams der Teilaufgaben/Arbeitspakete festlegen.


    Mein Anliegen:

    Ich würde nun gerne auch noch eine Reportingmethode einführen, die mich a) mit Infos zum Projektstand versorgt und b) auch die Stimmung der MA einfängt. Ich fürchte, dass wir einige Stellen haben, an denen interne Reibungsverluste drohen.

    Habt ihr Erfahrung mit solchen Projektstatusberichten? Was lief gut, was eher weniger? Wie waren sie aufgebaut, in welchem Format?

    Ein ellenlanger auszufüllender Bericht mit hübschem Ampelsystem, der am Ende gar nicht gepflegt und genutzt wird, ist ja auch nicht hilfreich. Kurz und knapp, dabei aber allumfassend wäre schön.


    Grundsätzlich kann ich auch Weiterbildungen und Seminare (in HH und B) dazu besuchen, was ganz passendes hab ich aber noch nicht gefunden. Neben eigenen Erfahrungen nehme ich auch gerne Links und Literaturtipps, um mich dazu zu belesen.


    #danke

    #post-2-3-4-5-6-7-8-9-10-11-12-13-14-15-#post-17-18-19-20-21-22-23-24

  • Würdest du verraten welche Branche es ist? Ich denk es ist ein riesiger Unterscheid, ob es z.B. ein Softwareentwicklungprojekt ist (da hätte ich glaub ich was) oder ein Automobilzuliefererprojekt oder ein Projekt im Öffentlichen Dienst oder im Sozialen Bereich.....

    In das hier hab ich mal reingeschaut und find es ganz umfassend:

    https://www.amazon.de/Modernes…m-Vorgehen/dp/3527530487/


    Weiss aber nicht mehr, ob es ein Template für einen Projektstatusbericht gibt

    Aufgrund meiner Einstellung zum Leben sehe ich keinen Grund, mich meines Alters entsprechend zu verhalten!

  • Hach, ja klar, die Branche wäre erwähnenswert #freu

    Wir sind Energieversorger und das Projekt ist ein Neubauquartier. Involviert sind bei uns also Menschen aus technischen (Wärme, Strom, E-Mobilität) und nichttechnischen (BWL, Öffentlichkeitsarbeit, PR, Marketing) Bereichen.


    Danke, den Buchtipp guck ich mir mal an.

    #post-2-3-4-5-6-7-8-9-10-11-12-13-14-15-#post-17-18-19-20-21-22-23-24

  • Oh, mein Thema :-)


    Solange es nicht Scrum oder agile PM ist (und danach klingt es für mich erstmal nicht), kann ich da helfen.

    Ich habe vor 3 Jahren einen IPMA Lehrgang in HH mit Prüfung in FRA gemacht, nur Level D, aber immerhin wurden dort alle Tools des PM gelernt und angewendet.


    Wir benutzen tatsächlich Ampelberichte, aber nicht ellenlang, sondern alles muss auf eine Powerpoint-Seite passen: Rationale, Milestones, Issues/Risks, Next steps und Required Decisions, alles mit jeweiligen Due Dates bzw. Finished Dates versehen. Die Ampel gilt dann nur für den kompletten Projektstatus, da bei Issues/Risks ja ggfs. auf Gefahren hingeweisen wird.

    Das ist dann aber alles rein faktenbasiert.


    Wenn Du zusätzlich noch Stimmungsbilder einfangen willst, solltest Du vorher auf jeden Fall eine Stakeholder-Analyse machen und diese auch iterativ laufen lassen, das sich ggfs. etwas ändern kann oder auch neue Akteure dazu kommen bzw. alte ausscheiden. Aus dieser Stakeholder-Analyse ergben sich dann auch jeweils die Kommunikationsstrategien für die jeweiligen Cluster.


    LG,

    Anne

    "Wer nicht mehr liebt und nicht mehr irrt, der lasse sich begraben" ~ Johann Wolfgang von Goethe

  • Ich bin - ebenfalls IPNA-zertifiziert - grosser Fan von Scrums in dieser Gruppengrösse.

    Wenn das Team dieses Tool routiniert benutzt, bist Du sehr schnell auf dem Arbeitsstand und hast gleichzeitig ein Stimmungsbild.


    Liebe Grüsse


    Talpa

  • Schade, in der Branche kann ich leider gar nicht helfen. Agile Softwareentwicklung und Scrum wäre mein Bereich ;)

    -----------------------------------------------


    Wunder 1: 07


    Wunder2: 11

  • Wir benutzen tatsächlich Ampelberichte, aber nicht ellenlang, sondern alles muss auf eine Powerpoint-Seite passen: Rationale, Milestones, Issues/Risks, Next steps und Required Decisions, alles mit jeweiligen Due Dates bzw. Finished Dates versehen. Die Ampel gilt dann nur für den kompletten Projektstatus, da bei Issues/Risks ja ggfs. auf Gefahren hingeweisen wird.

    Das ist dann aber alles rein faktenbasiert.


    Wenn Du zusätzlich noch Stimmungsbilder einfangen willst, solltest Du vorher auf jeden Fall eine Stakeholder-Analyse machen und diese auch iterativ laufen lassen, das sich ggfs. etwas ändern kann oder auch neue Akteure dazu kommen bzw. alte ausscheiden. Aus dieser Stakeholder-Analyse ergben sich dann auch jeweils die Kommunikationsstrategien für die jeweiligen Cluster.

    Danke, das hilft mir schon mal sehr weiter! Ich geh mal die von dir genannten Schlagworte durch und gucke, wie ich das für uns übersetze :D

    Auf jeden Fall muss ich mir noch ein bisschen theoretisches Wissen anlesen. Ich war im Alltagsgeschäft bisher eher nach Bauchgefühl und Erfahrungswerten unterwegs als mit extra dafür gelernten PM-Methoden.

    Ich bin - ebenfalls IPNA-zertifiziert - grosser Fan von Scrums in dieser Gruppengrösse.

    Wenn das Team dieses Tool routiniert benutzt, bist Du sehr schnell auf dem Arbeitsstand und hast gleichzeitig ein Stimmungsbild.

    Das klingt spannend, was genau kann ich mir denn unter einem Scrum vorstellen? Google sagt, das sind häufige (am besten sogar tägliche) und kurze Treffen. Meinst du, das klappt auch über Videokonferenz? Wir sitzen an mindestens fünf verschiedenen Standorten in Deutschland.

    Schade, in der Branche kann ich leider gar nicht helfen. Agile Softwareentwicklung und Scrum wäre mein Bereich

    Ist das jetzt nicht Trend, überall etwas agiler zu werden?;) Zumindest laufen mir diese Begriffe immer wieder über den Weg, wenn ich nach Projektmanagement suche, mit dem Hinweis, dass das im Softwarebereich so erfolgreich ist.

    #post-2-3-4-5-6-7-8-9-10-11-12-13-14-15-#post-17-18-19-20-21-22-23-24

  • Das Buch ist nun bestellt, die Kritiken lasen sich sehr positiv, ich bin gespannt. So eine Mischung aus agil und herkömmlichem PM ist für uns vermutlich das passende.

    Die Idee der Stakeholderanalyse hat meine Teamleiterin auch sehr begrüßt. Punkten im Job dank Rabenhilfe #super

    #post-2-3-4-5-6-7-8-9-10-11-12-13-14-15-#post-17-18-19-20-21-22-23-24

  • Scrum ist eine Methode, um agile Teams zu organisieren. Dazu braucht es aber auch den passenden Mindset, wenn der nicht da ist, ist die Einführung definitiv ein Change-Prozess, der seinerseits gemanagt werden muss.


    Das formale Reporting wird bei Scrum dadurch ersetzt, dass das Team alle X Wochen die Arbeitsergebnisse dem Auftraggeber präsentiert. Idealerweise fertige, nutzbare Teile.


    Deine Beschreibung klingt so, als ob Ihr eher nicht agil aufgestellt seid?

    Sage es mir, und ich werde es vergessen. Zeige es mir, und ich werde es vielleicht behalten. Lass es mich tun, und ich werde es verstehen.


    Konfuzius

  • Scrum ist eine Methode, um agile Teams zu organisieren. Dazu braucht es aber auch den passenden Mindset, wenn der nicht da ist, ist die Einführung definitiv ein Change-Prozess, der seinerseits gemanagt werden muss.

    unterschreib! Von " ich probiere mal Scrum oder irgendwas in aus der agilen Welt , wie Sprint Meetings , Retros oder Ähniches und nenne das dann Scrum" würde ich abraten. Um richtig Scrum zu machen, muss man die Organisation und das Mindset ändern, das ist denke ich ein hartes stück arbeit.

    Wobei nachtürlich nichts dagegen spricht, Retrospektiven oder Daily Meetings in einem eher klassischen Setting zu machen, aber das ist dann nicht Scrum.

    Aufgrund meiner Einstellung zum Leben sehe ich keinen Grund, mich meines Alters entsprechend zu verhalten!

  • Daily Meetings in einem eher klassischen Setting

    Das kann aber auch gruselig werden. Artet meiner Erfahrung nach oft in Rechfertigungs- oder Gähnrunden aus.


    Retrospektiven dagegen finde ich immer hilfreich. Aber jetzt wird's lansam OT ...

    Sage es mir, und ich werde es vergessen. Zeige es mir, und ich werde es vielleicht behalten. Lass es mich tun, und ich werde es verstehen.


    Konfuzius

  • ich kann nur agil :)

    Tröte aber bei klassischem Projektmanagment ins gleiche Horn: Auch dort während der Projektlaufzeit regelmäßig Retrospektiven machen, und nicht erst am Ende ein "Lessons Learned" oder "Postmortem" kann unglaublich hilfreich sein


    Viel Glück dir, das hört sich ja nach einem spannenden Großprojekt an :)

    "A complex system that works is invariably found to have evolved from a simple system that works. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over with a working simple system. "

    John Gall, The Systems Bible

  • Ich war im Alltagsgeschäft bisher eher nach Bauchgefühl und Erfahrungswerten unterwegs als mit extra dafür gelernten PM-Methoden.

    Alle erlernten Methoden sind im Grunde nur Tools, um ein Projekt zu steuern. Sie sind aber nichts, ohne Deinen mentalen Einsatz dabei ;-)


    Wenn Du das PM im Blut hast, kannst du auch ohne diese Tools auskommen, so wie eine Chefin: Sie hat in Mexiko ein Lager nach ihrem Bauchgefühl und ohne PM-Lehrgang im Hintergrund aufgebaut und es wurde pünktlich fertig ;-)

    (also, sie hat schon die "losen Enden" alle zusammen geschrieben, aber kein lehrbuchmäßiges PM betrieben).


    Der Lehrgang hat mir persönlich allerdings im Bezug auf folgende Punkte sehr weitergeholfen:

    - das Risikomanagement (das wird etwas griffiger dadurch und ich kann damit mein Bauchgefühl besser darstellen und habe gelernt, Risiken zu quantifizieren)

    - das bestmögliche Set-up für ein Projekt (man kann es ja unterschiedlich organisieren)

    - Abhängigkeiten sichtbar machen ("kritischer Pfad"), z.B. Du kannst beim Hausbau noch keine Kacheln im Bad anbringen lassen, wenn die elektrischen Leitungen noch nicht gelegt sind. Und wenn der Elektriker sich 3 Wochen verspätet, bedeutet es möglicherweise auch eine gewisse Verschiebung des Termins für den Fliesenleger. Bei komplexen Projekten kann so eine Verdeutlichung der Abhängigkeiten und der zeitlichen Auswirkungen hilfreich sein, i.e. wo hat man einen zeitlichen Puffer, wo hat man keinen.


    Falls Du für die Stakeholder-Analyse irgendwelche Materialien brauchst, schick mir einfach eine PN mit Deiner e-mail addy. Ich schicke Dir dann die Unterlagen des Lehrgangs, wie man sowas strukturiert und welche Schlüsse man aus den notierten Gegebenheiten ziehen kann, die dann letztlich auch die entsprechende Kommunikation an die jeweiligen Leute beeinflussen.


    LG,

    Anne

    "Wer nicht mehr liebt und nicht mehr irrt, der lasse sich begraben" ~ Johann Wolfgang von Goethe

  • Deine Beschreibung klingt so, als ob Ihr eher nicht agil aufgestellt seid?

    Ja, das könnte man so sagen. Wobei das nicht für alle gilt, mein direktes Team würde ich schon als eher agil einordnen (mit meinem rudimentären Verständnis, was "agil" bedeutet), in anderen Bereichen sieht es aber wieder ganz anders aus. Es wird wohl sehr viel Fingerspitzengefühl von uns brauchen, alle Beteiligten unter einen Hut zu bekommen und niemanden durch so neumodischen Kram zu verschrecken ;)


    Retrospektiven dagegen finde ich immer hilfreich. Aber jetzt wird's lansam OT ...

    Nene, gar nicht OT. Für mich ist das sehr hilfreich! Ich finde den Input von euch sehr bereichernd, da ich bisher ja so gar nichts mit PM zu tun hatte und mich da jetzt erstmal einarbeiten muss. Da helfen auch so Schlagworte sehr, um eine Idee davon zu bekommen, was überhaupt alles so üblich oder möglich ist.

    Alle erlernten Methoden sind im Grunde nur Tools, um ein Projekt zu steuern.

    Den Gedanken hab ich auch. Das sind alles Tools, um meinen persönlichen Werkzeugkasten zu füllen, aus dem ich dann im passenden Moment das passende Tool zauber. Ich hab z.B. auch mal als Weiterbildung eine "Kreativitätswerkstatt" besucht, und dort ganz tolle Methoden gelernt, um im Alltag kreativ zu werden und angeleitet Ideen zu sammeln, zu priorisieren usw. Ist vermutlich unter Ingenieur:innen nicht alltäglich, kam bei mir im Team aber sehr gut an, als ich einige Methoden davon dann auch in Meetings angewendet habe.


    Ich habe also nicht vor, mir eine PM Methode anzulesen und dann 1:1 umzusetzen, sondern zu gucken, was uns weiterhelfen könnte und ggf. zu modifizieren, so dass es zu uns passt.

    Viel Glück dir, das hört sich ja nach einem spannenden Großprojekt an

    Danke, das Projekt ist super spannend und herausfordernd für uns. Und ich freu mich auch sehr, dass ich nun in die Leitungsfunktion einsteigen darf, weil ich für mich persönlich viel Entwicklungspotential sehe und dieses Potential auch von meinen Führungskräften bei mir gesehen wird.

    Falls Du für die Stakeholder-Analyse irgendwelche Materialien brauchst, schick mir einfach eine PN mit Deiner e-mail addy. Ich schicke Dir dann die Unterlagen des Lehrgangs, wie man sowas strukturiert und welche Schlüsse man aus den notierten Gegebenheiten ziehen kann, die dann letztlich auch die entsprechende Kommunikation an die jeweiligen Leute beeinflussen.

    Danke für das Angebot, ich schick dir gleich eine PN.

    #post-2-3-4-5-6-7-8-9-10-11-12-13-14-15-#post-17-18-19-20-21-22-23-24

  • Das klingt spannend, was genau kann ich mir denn unter einem Scrum vorstellen? Google sagt, das sind häufige (am besten sogar tägliche) und kurze Treffen. Meinst du, das klappt auch über Videokonferenz? Wir sitzen an mindestens fünf verschiedenen Standorten in Deutschland.

    Ich bin überhaupt nicht geschult und lese interessiert mit, aber hierzu kann ich etwas sagen:


    Auf den Projekten in meinem Bereich gibt es manchmal Telefonkonferenzen, um den aktuellen Stand zu besprechen, und die fand ich oft nur so mittel-effizient. Ich denke, bei so etwas lohnt es sich darüber nachzudenken, wer jeweils teilnimmt, egal ob per Video- oder Telefonkonferenz.


    Wichtig finde ich immer, dass die Zuständigkeiten alle klar verteilt sind (am besten jeweils EINE hauptverantwortlich Person, damit Verantwortung nicht hin- und hergeschoben wird) und es mindestens eine Person gibt, die den Überblick über die verschiedenen Teilbereiche hat (besser zwei Personen).


    Was ich an deiner Stelle überlegen würde, wenn ich die Mittel dazu habe, wäre, ob sich möglichst bald alle, deren Arbeitsbereiche ineinandergreifen, einmal persönlich treffen. Ich finde, wenn man die Leute, mit denen man zusammenarbeitet, schon mal gesehen hat, hilft das schon ziemlich, und es kann auch helfen, Hemmschwellen zur Kommunikation abzubauen.

  • Die wichtigste Stelle wäre in meinem Team dann die Scrum-Masterin - als nicht Software-Entwickler arbeiten wir wahrscheinlich in einem sehr ähnlichen System wie Du: einzelne Teilbereiche, enger Zeitplan, Spezialisten und eine gemeinsame sehr fixe Deadline.

    Aber Scrum lässt sich da auch gut anpassen, frau muss es ja nicht so nennen.


    Wir machen regelmässig - je nach Belastung auch häufigere, in ruhigen Phasen eher mal eine auslassen - sehr routinierte Kurzsitzungen, geleitet von der Scrum-Masterin: jede:r informiert kurz und knackig (und tatataaaaa: da haben wir den grössten Störungsfaktor dieser Methode, das ist echt schwer für viele Leute) wo er steht, was erledigt ist, wo er "feststeckt" etc. Dann wir geklärt, wer dabei helfen kann, das Feststecken zu beheben, wer noch eine bilaterale Sitzung braucht und schon huschen wir alle wieder los, um weiter zu arbeiten.

    Es gibt durchaus solche Sitzungen, die länger dauern, weil die Störung nicht ein "mein Lieferant hat xy noch nicht geliefert ist", sondern es zwischenmenschliche Dinge sind - und da liegt meiner Meinung nach die Stärke der Methode, die sehr menschenbezogen ist. Der Platz zum "Kropf leeren" muss einfach sein und wird in dem Gefäss auch geboten.


    Liebe Grüsse


    Talpa

  • Was ich an deiner Stelle überlegen würde, wenn ich die Mittel dazu habe, wäre, ob sich möglichst bald alle, deren Arbeitsbereiche ineinandergreifen, einmal persönlich treffen. Ich finde, wenn man die Leute, mit denen man zusammenarbeitet, schon mal gesehen hat, hilft das schon ziemlich, und es kann auch helfen, Hemmschwellen zur Kommunikation abzubauen.

    Absolut wichtig, ja.

    Das nennt sich bei uns Kick-off Meeting, also ein initiales Projekt-Vorstellungsmeeting.

    Der Projektleiter stellt das Projekt vor und alle Eingeladenen (Workstream-Leads oder auch einfach nur Projektmitglieder, die Arbeitspakete abarbeiten stellen sich selbst vor, also in welchem Bereich sie arbeiten, zu welchen Stream sie gehören und welches ihre groben Aufgaben sind.



    Wichtig finde ich immer, dass die Zuständigkeiten alle klar verteilt sind (am besten jeweils EINE hauptverantwortlich Person, damit Verantwortung nicht hin- und hergeschoben wird)

    Viele Projekte scheitern genau daran.

    Daher sieht das Projektmanagement nach Lehrbuch vor, dass man alles klar strukturiert, bis runter zum einzelnen Arbeitspaket:

    Was genau (wirklich detaillierte Aufgabenbeschreibung, inkl. Schnittstellen und vorangehende Tätigkeiten, sowie nachfolgende Tätigkeiten) soll bis wann (genaues Datum benennen) von WEM (konkereter Name, keine Abteilung oder so) erledigt werden.


    Für jedes Arbitspaket gibt es eine verantwortliche Person. Idealerweise schreibt sie als Expertin selbst das Arbeitspaket oder wird vom von der (Teil-)Projektleiterin damit vertraut gemacht.


    LG,

    Anne

    "Wer nicht mehr liebt und nicht mehr irrt, der lasse sich begraben" ~ Johann Wolfgang von Goethe

  • Gute Software hilft immer. Seitdem wir Jira und skype (chat) einsetzen läuft die zusammenarbeit mit manchen standorten in anderen Ländern viel besser da sich die Kollegen dort schwer tun (und taten, es bessert sich ja auch immer mit der Übung) sich im englischen an telecon- diskussionen zu beteiligen. Aber schriftlich flutscht es besser bzw kommen auch detaillierte statusberichte oder problembeschreibungen an.

    mit zwei Jungs (2010 und 2012) schon lange nicht mehr mit tapatalk unterwegs aber endlich wieder mit laptop im Forum