Übergabe eines Programmes in 6 Phasen

2 min.

Summary

Sobald Sie ein Programm übergeben, sollten Sie einige Dinge bei der Vorbereitung und Übergabe selbst beachten. Hier hat sich für mich ein 6-Phasen-Ansatz bewährt welcher bei mir immer wieder eingesetzt wird.

1. Preparation (so früh wie möglich!)

  • Abstimmung mit den Stakeholdern
  • Überblick über den Wissenstransfer-Plan
  • Budget für Wissenstransferperiode vereinbaren
  • Suche nach einem Nachfolger und Erhalt der Zustimmung zu einer bestimmten Person von Stakeholdern
  • Endgültiges Startdatum des Nachfolgers bestätigen (Zeitleiste des Wissenstransferplans anpassen)

2. On-Boarding (-3 Wochen)

  • Nachfolger startet im Projekt als zusätzliche Ressource
  • Projektvereinbarung definieren
  • Nachfolger in allen regulären Administrationstätigkeiten wie Zugriffsrechte, Kalendereinladungen, Übergabeprozessdokumentation etc. einbinden
  • Nachfolger im Newsletter vorstellen

3. Shadowing (-2 Wochen)

  • Nachfolger war Ihr bisheriger Stellvertreter, wenn möglich.
  • Der Nachfolger nimmt auch in Ihren besuchten Meetings teil.
  • Der Nachfolger beobachtet alle Ihre Kernaktivitäten.
  • Nachfolger aktualisiert und ändert gemeinsamen Plan für den Wissenstransfer und leitet Aktivitäten ein.

4. Re-Shadowing (-1 Woche)

  • Nachfolger übernimmt Verantwortung
  • Räumen Sie Ihren Schreibtisch und übergeben Sie ihn an den Nachfolger
  • Der Nachfolger leitet alle Ihre früheren Meetings
  • Der Nachfolger ist für alle Ihre bisherigen Prozesse verantwortlich
  • Stehen Sie zur Verfügung für alle Fragen Ihres Nachfolgers

5. Backup (beginnt mit dem Tag der Übergabe)

  • Weniger Präsenz zeigen, nur an internen Teambesprechungen teilnehmen, aber keine Kundengespräche
  • Seien Sie für jede Hilfe für Ihren Nachfolger da
  • Bereiten Sie sich darauf vor, einige operative Tätigkeiten zu übernehmen um den Nachfolger bei der Einarbeitung zu entlasten
  • Senden Sie alle noch eingehenden Anfragen / Fragen an Ihren Nachfolger

6. Phase Out (+1 Woche)

  • Erledigen Sie alle Off-Boarding-Aktivitäten selbst
  • Projektvereinbarung auflösen
  • Seien Sie da, um Ihrem Nachfolger zu helfen
  • Nehmen Sie keine Betriebsaufgaben mehr an
  • Geben Sie eine Abschiedsparty und verabschieden Sie sich im Newsletter
  • Senden Sie alle noch eingehenden Anfragen / Fragen an Ihren Nachfolger
  • Gehen Sie! (+2 Wochen)

Erfolgsfaktoren für eine ordnungsgemäße Übergabe

  • Binden Sie Kunden und alle Stakeholder frühzeitig ein.
  • Ordnen Sie Prozesse nicht programm- / personenzentriert an, sondern prozess- / verantwortungsszentriert.
    • Seien Sie nicht selbst Single Point of Contact für mehrere Prozesse,
    • Machen Sie stattdessen jedes Ihrer Teammitglieder von Anfang an für einen oder mehrere Prozesse verantwortlich (Management by Objective).
  • Planen und bereiten Sie Ihre Übergabe als eigenes Projekt vor.
  • Erstellung eines Wissenstransferplans, der von allen Beteiligten abgestimmt werden muss.
    • Aufschlüsselung des Wissenstransfers in granulare Aktivitäten (1-3 Stunden).
    • Bitten Sie Ihren Nachfolger, diesen Plan zu pflegen und jede abgeschlossene Aktivität abzuhaken.
    • Behandeln Sie diesen Plan und aktualisieren Sie ihn wie jeden anderen Projektplan.
  • Kommunizieren Sie Ihren Weggang dem gesamten Team spätestens zu Beginn der Wissenstransferphase.
  • Sehen Sie nach erfolgreichem Wissenstransfer eine Backup-Phase vor von bis zu zwei Wochen.
  • Definieren Sie ein klares Übergabedatum im Wissenstransferplan.

Viel Spaß in Ihrem neuen Projekt / Programm!

Agiler Wirbel?!

3 min.

Summary

Agile Arbeit bzw. Lieferung ist nur möglich, wenn notwendige Entscheidungen stets abgerufen werden können. Ebenso funktioniert es ohne entsprechende Governance nicht. Die Arbeitsweise in Turnaround-Situationen von klassischen Projekten ähnelt sich stark mit dem Ansatz agiler Projekte. Hier wird der Fokus auf kurze Iterationen und enge Abstimmung mit dem Kunden gelegt. Aus dieser Beobachtung heraus sollte die Einführung von agilen Prinzipien entsprechend erfolgen. Agile Prinzipien werden sich in unterschiedlichen Branchen auch weiterhin unterschiedlich verbreiten. Wer nun aber Agilität mit Methode oder Technologie verbindet liegt falsch! Frühe Ergebnisse im Projekt und enge Abstimmung mit dem wirklichen Kunden sind keine Methoden- oder Toolergebnisse.

Agiles Projektmanagement funktioniert ohne entsprechende Governance nicht

Agile Arbeit bzw. Lieferung ist nur möglich, wenn notwendige Entscheidungen stets abgerufen werden können. In meinem Beitrag „Kommunikationsprinzipien in einem Projekt“ ist gut zu erkennen, dass die kurze Dauer bis zu einer Entscheidungsfindung extrem wichtig ist. Diese wird oft durch die mittleren Schichten des Managements in einem Unternehmen verlangsamt oder gar blockiert. Dieser sogenannte Permafrost kann die vom Top-Management oft sinnvollerweise identifizierte Notwendigkeit von Agilität nicht nachvollziehen. Diese Schicht will ebenso im Projektverlauf die notwendigen Entscheidungen nicht selbst treffen, aber platziert diese dann auch nicht richtig beim Senior Management.

Agiles Projektmanagement ähnelt sich stark mit dem Ansatz klassischer Projekte in Turnaround-Situationen

Bei agilem Projektmanagement und bei Turnaround-Situationen von klassischem Projektmanagement wird der Fokus auf kurze Iterationen und enge Abstimmung mit dem Kunden gelegt. Aus dieser Beobachtung heraus sollte die Einführung von agilen Prinzipien entsprechend erfolgen. Der klassische Projektplan ist dann meist nur Referenz für vertragsrelevante Liefergegenstände. Die Kette des Versagens bei Projekten ist die Kundenbeziehung und damit die Governance-Struktur, danach die Tools und Prozesse und spätestens anschließend die Mitarbeiterfrustration. Bei der Einführung von agilen Prinzipen ist die Sequenz genau anders herum. Wobei meiner Erfahrung nach kann in Projektorganisationen die Teamstimmung zu jeder Zeit vielfältigste Probleme anzeigen und nicht nur pauschal, dass „etwas“ nicht stimmt, sondern auch in welchen Projektmanagement-Domänen (siehe mein Beitrag Teamstimmung). Interessant wäre hier bei der Einführung von agilem Projektmanagement ebenfalls diese Methode zu verwenden.

Wie wird der agile Wirbel sich nun verbreiten?

Wie in meinem Beitrag „Projektleiter im Jahre 2030“ abzuleiten ist, werden sich die agilen Prinzipien in unterschiedlichen Branchen auch weiterhin unterschiedlich schnell und stark verbreiten. Wie diese „Agilität“ dann aussehen wird, ob reines SCRUM, SRUM of SRCUM, Kanban, scaled agile, SAFe, LeSS oder Spotify wird durch die Kunden- und Unternehmensumgebung (also Produkte, Dienstleistungen, Branche, Größe usw. geprägt). Ist das „klassische Projektmanagement“ damit tot? Sicherlich nicht, denn es gibt bestimmte komplexe (sehr große Programme) und komplizierte (Wiederholungsprojekte) für die das klassische Projektmanagement die bessere Alternative sein wird. Sinnvollerweise wird der klassische Projektmanager dennoch Tool-Picking aus der agilen Box machen. Wer nun aber Agilität mit Methode oder Technologie verbindet liegt falsch! Frühe Ergebnisse im Projekt und enge Abstimmung mit dem wirklichen Kunden sind keine Methoden- oder Toolergebnisse. Konzepte und Planung sind in beiden Ansätzen erforderlich. Diesem Aspekt tragen Ansätze wie die skalierten agilen Ansätze wie z. B. SAFe besonders Rechnung.

Die Herausforderungen für Product Owner oder Projektmanager

Die Herausforderung für die Treiber von Vorhaben, ob nun Product Owner, Projektmanager oder Programm-Manager wird nun sein, dass diese in unterschiedlichen Umgebungen unterschiedliche Klaviaturen spielen sollen. Denn die dogmatische Ausrichtung „wir machen nur agile Einzel-Projekte“ kann nur in Unternehmen erfolgen, die keinen Bedarf für andersartige Schnittstellen und Umgebungen haben. Der reine Agile Product Owner oder klassische Programmmanager wird daher eher die seltene Spezies bleiben. Eine Stigmatisierung der beiden Ansätze ist daher sicherlich nicht sinnvoll, sondern die kombinierte Anwendung bzw. schlicht gesagt das agile klassische Projekt ist die Zukunft. Frühe und stete Resultate und enge Endkundenabstimmung sind in allen Vorhaben der Erfolgsfaktor.

Dieser Artikel entstand im Rahmen der Blogparade des Projektmagazins.

Projektplanungssoftware – alles nur Mist?!

1 Minute


Summary

Die Projektplanungs- und Steuerungssoftware nur als visuelle Darstellung des Planungsstandes zu nutzen ist vergeudete Zeit. Einige wenige Tipps sind zu befolgen und MS Project und Co sind auch für die Projektüberwachung und -steuerung sehr sinnvoll einzusetzen.

Ich höre immer wieder von angehenden Projektmanagern, aber auch von erfahrenen Projektmanagern, dass ein Projektsteuerungstool wie z. B. MS Project nicht praktikabel einzusetzen ist. Es sei zu kompliziert und die eigentliche Steuerung sei damit auch nicht wirklich möglich.

Wenn Du folgende Tipps beachtest geht nichts mehr schief

  • Stelle in den Optionen ein, dass MS Project oder das Tool Deiner Wahl die Planung auf „feste Arbeit“ basiert
  • Die Verfügbarkeiten (Stundenkapazität und Urlaube) der Ressourcen/Qualifikationen müssen im Projektkalender eingetragen werden.
  • Kein manuelles Datum (Termin) setzen, außer Projektstart oder Endtermin.
  • Für jeden Vorgang / Arbeitspaket muss ein Vorgänger (zumindest der Projektstartmeilenstein) und Nachfolger (zumindest der Projektendmeilenstein) eingetragen werden.
  • Keine Dauer eingeben, sondern nur Aufwand für den Vorgang / Arbeitspaket.
  • Für jeden Vorgang sollte nur eine Ressource/Qualifikation eingetragen werden.
  • Den kritisch Pfad im Ablauf- und Terminplan (Gantt) immer anzeigen lassen. Dieser muss durchgängig über die gesamte Projektlaufzeit ohne Unterbrechung angezeigt werden. Ansonsten liegt ein Fehler vor, wie z. B. manuelles Datum gesetzt.
  • Plane nur maximal 2-3 Monate rollierend im Detail (Ressourcen und Aufwände) voraus.

Und das letzte Hemmnis ist dann immer wieder, dass Dein Unternehmen keine MS Project Lizenz für Dich investiert. Dann besorge Dir ProjectLibre als Opensource oder eine andere Freeware.

Kommunikationsprinzipien in einem Projekt

2 min.

Summary

Die ersten Stunden oder zumindest Tage innerhalb eines Projekts prägen den Großteil der laufenden Kommunikation in einem Projekt oder Programm. Mit anderen Worten: Wenn Sie in einem Projekt keine oder zu spät Kommunikationsprinzipien definieren, müssen Sie sich später mit Problemen auseinandersetzen: Alle „weichen“ Themen wie die Nutzung von Mobiltelefonen oder Laptops bei Meetings, Respekt untereinander, Zuhören, Verständnis bestätigen, Teilnahme aller an Meetings, statt Mails besser anrufen und so weiter und so fort sind Themen, die oft leichter zu verfolgen sind als das individuelle Verhalten in folgenden Themen. Daher sollte eine Anleitung ausgegeben werden. Ein Beispiel meiner Standardkommunikation, die in Projekten etabliere.

Sinnvolle Kommunikationsprinzipien

Ich möchte Sie bitten, folgende Kommunikationsprinzipien zu befolgen.

Um unseren Mailverkehr zu minimieren und die Organisation unserer Mailboxen zu erleichtern, sollten wir uns auf folgende Regeln einigen:

  • Senden Sie nur Mails an die Teammitglieder, die die Informationen benötigen!
  • Klingt selbstverständlich, aber gemeint ist: Vermeide große Verteiler ohne Grund.
  • Solange wir an Entwürfen oder an der Fertigstellung von Vorlagen arbeiten, werden die Entwürfe nur an das definierte Team verschickt.
  • Häufig werden große Kopienverteiler in Mails zur Eskalation um auf Nummer sicher zu gehen verwendet: Bitte kontaktieren und informieren Sie den Programm-Manager bzw. das gewünschte Teammitglied vorher.
  • Die Stream Leads werden gebeten, einen Workaround für die interne Eskalationsverarbeitung in ihren Streams zu entwerfen, da wir alle der Meinung sind, dass die Arbeit von uns allen sehr wichtig für dieses Programm ist! Aus diesem Grund werden nur Mails mit einer kritischen Zeitachse als dringend markiert.
  • Mails mit einer kritischen Auswirkung auf den Programminhalt müssen im Betreff mit URG markiert werden
  • Um eine Überlastung der Kapazität unseres Mail-Servers zu vermeiden, senden wir Links, wo immer es möglich ist.
  • Last but not least: Vergraben Sie nicht die benötigten Informationen in E-Mail-Ketten….

E-Mail Richtlinie

  1. Alle Mails müssen mit der Art der Informationen gekennzeichnet sein, die in der E-Mail angegeben sind.
  • INF: Information; eine Information wird die Adressaten gegeben, es besteht kein Handlungsbedarf.
  • ACT: Datum, Aufgabe; und die Aufgabe ist vom Empfänger zu erledigen.
  • DEL: Lieferung; eine angeforderte Lieferung erfolgt.
  • URG: Dringende Informationen beginnen mit diesem Präfix.
  • z. B. URG: DREAM: SP01: …. – siehe auch Dateinamenskonvention
  1. Mail subjects needs to include a short and clear description of the content
  2. Addressees on copy have in general no action!
  3. Escalations
    In general the escalations come up as followed:
    1. Team Members to Subproject Managers
    2. Subproject Managers to Project Management
    3. Project Management to Program Sponsor / SteercoE.G.: INF: DREAM: SP01: Mail Convention

Dokumentnamens-Konvention

Alle Dokumente im Programm sind wie folgt benannt:

  1. Datum (yyyymmdd)
  2. Projektname (DREAM) und Unterprojektnummer (z. B. SP01)
  3. Dokumentname
  4. Version (Entwürfe V 0.1 ff; fertige Versionen V 1.0 ff)

Z. B.: 20170220_DREAM_WP01_name convention_V 0-1.doc

Die vier Elemente sind durch einen Unterstrich getrennt.

Alle Dokumente, die reviewed wurden, folgen dieser Namenskonvention:

  1. Name des Originaldokuments
  2. Rev<Initialen des Reviewers>
  3. Reviewdatum (yyyymmdd)

z.B.: 20170220_DREAM_WP01_name convention_V 0-1_RevMW_20170307.doc

Besprechungsagenda

1 Minute

Summary

Effektive Meetings sind immer eine Herausforderung. Es gibt viele Regeln und Checklisten für Meetings. Aber bis jetzt habe ich noch keine gute Vorlage für eine effektive Meeting-Agenda gefunden.

In meiner täglichen Anwendung habe ich den Bedarf an zwei verschiedenen Agenda-Formaten festgestellt, abhängig von der Dauer der Sitzung oder besser der Anzahl der Agenda-Themen.

Für eine Telefonkonferenz

verwende ich seit Jahren immer das folgende einfache Format (falls nicht viele Themen behandelt werden müssen):

INITIAL SITUATION/AUSGANGSSITUATION
  • Der Projektstatus muss bis Freitag 12:00 Uhr MEZ an Steerco gemeldet werden.
PREPARATION NEEDED / ERFORDERLICHE VORBEREITUNGEN (including owner)
  • Bitte aktualisieren Sie Ihre Arbeitspakete bis Donnerstag 10:00 Uhr CET Server Link (ALLE).
  • Bitte aktualisieren Sie den Status der Aktionspunkte / Server link (ALLE)
  • Berichtsvorlage aktualisieren (ML)
AGENDA
  • Überprüfung von Schnittstellenproblemen zwischen Arbeitspaketen (MW)
  • Abstimmung von Aktionspunkten über Arbeitspakete hinweg (MW)
  • Abstimmung über Teamdiskussionen auf dem Projektserver (ML)
  • Probleme und Risiken, auf die es abzustimmen gilt (ML)
RESULTS EXPECTED OF THE MEETING/ ERWARTETE ERGEBNISSE DES MEETINGS
  • Abgestimmte Sicht auf Projektstatus
NEXT STEPS AFTER THE MEETING/ NÄCHSTE SCHRITTE IM NACHGANG ZUM MEETING
  • Zu konsolidierender Bericht (ML)
  • Bericht zur Überprüfung und Übermittlung an Steerco (MW)

Für Präsenz-Workshops oder längere Telkos

bevorzuge ich das folgende Format:

Berlin, Hauptstr. 14-16, 1.OG, Raum E1.15a, Montag 05. Feb 2018 – CMO FMO Big Picture
Ziel: Gemeinsames Verständnis von CMO und FMO Big Pictures und damit verbundenen Aktivitäten
Ansatz: Time Boxing
Vorbereitung: Präsentation: Serverlink
Materialien: 2 Beamer, Moderationskoffer
Zeit (CET)ThemaHostInput und Vorbereitung erforderlich / VerantwortlicherErgebnis erwartet / VerantwortlicherTeilnehmer
09:30 – 10:00Einführung und Ziel der BesprechungMW Einführung – keine Vorbereitung erforderlich Alle Alle

Projektleiter im Jahre 2030

6 min.

Summary:

Gibt es den Projektleiter im Jahre 2030 noch – wie wir ihn heute kennen? Die Antwort in Kürze: Nein. Im Bereich Führung, der Organisation als auch in der Umsetzung des Vorhabens werden sich die Aufgaben der Projektleiter verändern.

Es hat mich gereizt bei der Blogparade des Projektmagazins mitzumachen. Denn zum einen sprechen wir hier über einen Begriff „Projektleiter“ der heftig in die Diskussion geraten ist und zum anderen über einen Zeitraum, der selbst für Zukunftsforscher sehr lange ist. Die Forscher trauen sich selbst nicht in dieser Zeitdimension festzulegen.

Der Projektleiter als Begriff

Beide Teile des Wortes Projektleiter sind derzeit in großer Diskussion, ob diese aussagekräftig oder gar noch zeitgemäß sind. Projekte werden wie z. B. im BI von Otto als nicht mehr erforderlich gesehen. Der (Projekt-) Leiter oder Projektmanager ist im reinen agilen Set nicht vorgesehen. Hier wird Führung oder Leadership noch einen wichtigeren Fokus bekommen als ohnehin heute schon. Leiter im Sinne von steuern und lenken wird immer weniger relevant werden aufgrund der bereits jetzt sichtbaren Entwicklungen.

Es ist problematisch eine Zukunftsaussage über den Projektleiter in 2030 zu geben, wenn bereits heute der Begriff als solches nicht mehr die Verankerung hat, wie vielleicht in den vorhergehenden Jahrzehnten. Wagen wir einen Versuch.

Der Maßstab Zeit

Bis 2030 sind es noch 12 Jahre. Erscheint lange. Wenn man überlegt wie die Welt aussah, vor 12 Jahren, von heute 2018 rückwärts gerechnet: Es gab kein iPhone, kein Android, keine Apps, kein Youtube, kein Spotify, kein Kindle, kein Tablet, keinen digitalen Vollformatsensor in einer Serienkamera (um auch mein Hobby in den Kontext zu bringen). Man erkennt es passiert mehr in 10 bzw. 12 Jahren als man annimmt. Deshalb rechnen Zukunftsforscher nicht in Jahren, sondern in Wochen, um die Kurzfristigkeit zu betonen und um die Zukunftsmodelle und -aussagen schneller zu bewerten und vergleichbarer zu machen. Der Zukunftsforscher nimmt 50 Wochen pro Jahr an. Wie viele Wochen seit Neujahr sind schon wieder vorbei? Drei. Also weniger als 50 Wochen bis Neujahr. In diesen drei Wochen sind nach dem menschlichen Gefühl nicht viele Dinge passiert. Im besten Falle haben Sie dreimal eine Wochenplanung gemacht und dreimal ein Resümee gezogen. Aber die „Wochen-übergreifenden“ taktischen Themen erscheinen nicht signifikant. Dennoch arbeiten Projektmanager, Scrum Master oder Ein-Mann-Unternehmen an den revolutionären Aspekten der Zukunft. In den nächsten 597 Wochen bis zum Jahr 2030.

Wie sieht das Projektumfeld aus in 500 Wochen?

Wie sieht die Welt in 500 Wochen aus? Ziemlich sicher scheint: In 500 Wochen werde ich und 70% der deutschen Bevölkerung kein Auto mehr besitzen.  In 500 Wochen werden wir keine Smartphones mehr besitzen. In 500 Wochen werden wir keinen Supermarkt mehr nutzen. In 500 Wochen werden wir mehr Strom in den Haushalten produzieren als wir konsumieren. In 500 Wochen werden wir Fleisch aus Laboren gezüchtet essen. In 500 Wochen werden wir Ohren für Menschen aus dem 3D-Drucker als medizinische Ersatzteile erhalten. In 500 Wochen werden Roboter die Pflege von alten Menschen unterstützen. In 500 Wochen werden 40% der deutschen Bevölkerungen intelligente nicht-medizinische Implantate besitzen. In 500 Wochen …

All diese Vorhaben – nennen wir sie mal hier einfachheitshalber Projekte – werden von Menschen begleitet. Es geht hier nicht um die Generierung der Ideen, sondern um deren Umsetzung. Dass Ideen-Gebung, -definition und -umsetzung personell nahe beieinander liegen sollen, befürworten die einen und kritisieren die anderen.

Anforderungen an die heutigen Projektleiter im Jahr 2030

Welche Auswirkungen hat dies denn auf mich und alle anderen Projektleiter aus dem Jahre 2018? Der Visionär Projektmanager, der diese eine Idee treibt, wird so nicht mehr existent sein. Wir erkennen bereits heute wie komplex die Arbeitswelt und die Welt als solches geworden ist. Dies kann nicht mehr eine Person in sich vereinen. Es wird also immer mehr eine Teamleistung sein müssen. Was gut ist. Dies wirkt sich selbstredend auf den Aspekt der Führung aus. Wir erkennen Trends bereits in agilen Ansätzen die aber noch nicht das Ende der Fahnenstange darstellen. Die nachkommenden Generationen haben und fordern eine andere Einstellung zur Arbeit. Das habe ich schon vielfach selbst erlebt und rede auch schon wie meine Opas („Die jungen Leute heutzutage“). Aber auch diese Veränderung ist gut, denn …

“Ohne Veränderung keine Entwicklung.”
Birgit Ramlow (*1948), Angestellte und Hobby-Aphoristikerin

Transformation vs. Revolution

Und nun ein viel kritisierter Begriff aus der BWL: Transformation. Wenn ich in Wochen denke und Vorhaben in einem überschaubaren Zeitrahmen gestalte hat man transformationelle Aspekte. Revolutionär ist es, wenn wir einen kompletten Technologie- oder Paradigmenwechsel erleben. Das Smartphone war keine Revolution, sondern eine mutige und kreative Zusammenstellung von verfügbaren Technologien. Der Push kam etwas verzögert erst durch die Apps. Aber auch diese sind keine klassische Revolution, sondern eine Weiterentwicklung auf einer anderen Plattform und daher durch mehr Nutzer eingesetzt. Wieso wurde denn das Smartphone letztendlich doch als revolutionär empfunden und hat auch diesen äußeren Anschein? Nun, meine These ist, dass Manager von Konkurrenten wie Nokia und Siemens nicht mutig genug waren und nicht auf den Markt gehört haben. Die Vorstellungskraft bzw. Kreativität hat nicht gefehlt. Denn auch den Autobauern wird heute die ganze Entwicklung vorhergesagt und die Reaktionen darauf sind meiner Meinung nach zu zögerlich. In Entwicklungszeiträumen von 4 Jahren pro wirklichen Modellwechsel, also 200 Wochen, kann man in der heutigen Zeit nicht mehr agieren. Was können wir also daraus für den Projektleiter ableiten?

Er wird viel in Transformationsvorhaben mitarbeiten und wird bei mutigen und schnell agierenden Geschäftsführungen durch das schnelle Platzieren von neuen Vorhaben damit zur Revolution beitragen.

Unternehmensführung oder Gremien in 2030

Die größten Veränderungen werden sicherlich noch eine Ebene höher (wenn man davon überhaupt sprechen mag – heute zumindest eine Ebene höher) erforderlich sein beim Portfolio-Board, bei den Product Ownern oder wie auch immer ein Unternehmen für sich die strategische Entscheidungsfindung implementiert. Bei Otto im Produktbereich, im agilen Umfeld durch den Product Owner – als Vertreter für die Geschäftsleitung oder das Portfolio-Board im klassischen Projektmanagement. Diese Gremien werden sicherlich noch mehr, als in meinem im Jahre 2016 verfassten Artikel, dem definierten Anspruch gerecht werden müssen, um die Taktung zwischen den Transformationen hin zu Revolutionen zu ermöglichen. Und seien wir mal ehrlich, in den ~ 60 Wochen seit dem dieser Artikel verfasst wurde, ist der Anspruch immer noch nicht erfüllt. Es gibt also Handlungsbedarf.

Unterschiedliche Anforderungen an die Projektleiter

Wird die Entwicklung abhängig sein von der Projektart?

Es wird nicht mehr den Projektleiter geben der universell in allen Branchen und Projektarten Projekte leiten kann. Zumindest die heutige Anspruchshaltung hierzu wird immer weniger zutreffend sein.

Im Bereich der Softwareentwicklung werden sich agile Ansätze und für große Programme hybride Mischformen entwickeln. Eine Ausgestaltung dieser Mischformen ist Material für einen weiteren Blogbeitrag.

Investitionsprojekte werden weiterhin ähnlich organisiert sein wie heute. Und damit auch die Rolle und Aufgabenstellung des Projektleiters. Auch wenn die heutigen Beispiele, wie Berliner Flughafen, nicht vielversprechend sind.

Der junge Projektmanager in 2030

Was ist aber mit dem jungen Projektleiter der im Jahre 2030 erstmals Projekte managen soll? Dieser startet mit einem Handicap. Denn er selbst, aber auch seine IT-Architekten und anderen Kollegen, werden hier in Deutschland keine „Gesellenjahre“ mehr erlebt haben, da alle „Gesellentätigkeiten“ schon in den 90er Jahren aus dem letzten Jahrhundert Nearshore oder Offshore verlagert wurden. Ein einsteigen in den Beruf Projektmanager, wie auch immer der geformt ist, wird nicht mehr so einfach möglich sein.  Dies beobachtet man heute in der schon vor länger veränderten Umfeldern, wie in der Textilindustrie. Hier gibt es heute oft in Deutschland Probleme qualifizierte Näherinnen für die Musterkollektion zu finden. Deshalb müssen Firmen selbst unternehmenskritische Bereiche wie Design und Musterkollektion ins Ausland verlagern. So wird es auch mit den Projektmanagern der Zukunft sein. In der virtuellen Welt, mit den unterstützenden Technologien, wird dies immer einfach sein trotzdem hier in Deutschland noch Projekte durchzuführen. Aber auch die Nähe zum Kunden ist aufgrund der virtuellen Unterstützungstechniken immer weniger wichtig. Das heißt, Vorhaben werden in 2030 auch komplett von remote aus durchgeführt werden können (inkl. Projektleiter), ohne die Kundennähe in Deutschland zu vermissen.

Projekt-Steuerungs- und Lenkungsgremien – verstehen, formen und nutzen

4 min.

Wieso bewegt uns das Thema Gremien als Projektmanager? Wir benötigen für unsere Projekte klare Entscheidungen in Fällen, in denen unsere Befugnisse nicht ausreichen. Wieso ist es oft schwer diese notwendigen Entscheidungen zeitnah, klar und präzise zu erhalten?

Dafür müssen wir verstehen, dass es unzählige Begriffe für ein und das Selbe gibt … und viele Begriffe mehrfach belegt sind in der Praxis.

Zu den daraus folgenden typischen Problemen mit den Gremien komme ich später.

Wo können wir hier Lösung finden? PMI klammert Rollenbeschreibungen und Aufbauorganisation auf. Hier kann uns also nicht geholfen werden. Prince2 definiert die genannten Gremien detailliert und harmonisch mit IPMA bzw. GPM.

Die DIN 69901-5 definiert den Lenkungssauschuss als  „übergeordnetes Gremium, an das der Projektleiter berichtet und das ihm als Entscheidungs- und Eskalationsgremium zur Verfügung steht.“
Das hilft nicht wirklich umfänglich weiter.

Dann schauen wir mal wie der PM3 (bei Amazon) der GPM uns unterstützt.

Was sind Steuerungsgremien? Diese können auf allen Meeren in alle Himmelsrichtungen das Steuerruder des Schiffes ausrichten.

Diese Steuergremien sind … intern und … projektübergreifend. Synonyme Begriffe definiert Patzak/Rattay (bei Amazon) als Steering Commitee, Steuerungsgruppe und Projektbeiräte. Die Aufgabe dieses Gremium ist die Auswahl von Projekten und die Zusammenhänge von Projekte zu analysieren, beobachten und zu steuern.

Der Lenkungsausschuss wir auch im Duden … meiner Meinung nach sehr gut … definiert. Nämlich als „Ausschuss für die wirtschaftliche Lenkung“. Hier geht es also im Gegensatz zum Steuerungsgremium nicht um die generelle Sinnbestimmung eines Projektes, sondern die wirtschaftliche Beobachtung und Einflussnahme. Der Lenkungsausschuss ist also nur am Lenkrad im Auto auf vorgegeben Straßen und kann entscheiden an welchen Kreuzungen welche Richtung eingeschlagen werden soll.

Dieses Gremium, der Lenkungsausschuss, kann auch externe Partner wie wichtige Lieferanten oder den Endkunden inkludieren.

Im PM3 wird festgehalten, dass es in den Organisationen keine einheitlichen Regeln gibt wie Steuerungsboards arbeiten sollen. Es ist also von Unternehmen zu Unternehmen unterschiedlich. Allerdings lässt sich eine typische Verantwortung herausarbeiten. Das Steuerungsgremium

  •          Ernennt den Projektmanager
  •          Wählt Projekte aus
  •          Stoppt Projekte
  •          Initiiert Projekte und prägt die
  •          Grobe Zielfestlegung.

Auch für den Lenkungsausschuss beschreibt der PM3 typische Verantwortungsbereiche. Diese sind

  •          Verfolgung des Projektfortschrittes
  •          Konflikte und Befugnisse zwischen Linie und Projekte zu klären
  •          Meilensteine und Projektergebnisse abzunehmen
  •          Eskalation an Unternehmensführung bzw. Portfoliomanagement und
  •          eventuell, falls es kein separates Change Board gibt, die Entscheidung von Änderungsanträgen.

Was müssen wir nun als Projekt- und Programmmanager tun um durch Gremien erfolgreich unterstützt zu werden. Hierfür erläutere ich die nach meiner Erfahrung nach wichtigsten Punkten.

  • Wir müssen diese Gremien formen in dem wir
  • notwendige externe Partner einbinden
  • hoch in der Hierarchie angesiedelte Mitglieder für die Gremien gewinnen
  • fordern, dass ein Sprecher des Gremiums festgelegt wird
  • Eskalationsinstanzen und Lösungsdauern auf den jeweiligen Eskalationsstufen vereinbaren und auch das
  • Änderungsmanagement vereinbaren.

Welche Voraussetzungen bzw. Wissen ist in den Steuerungsgremien erforderlich? Diese müssen laut Patzak / Rattay Transparenz und Wissen über die Unternehmensstrategie besitzen und Kenntnisse über das Projektportfolio. Ansonsten kann das Steuerungsgremium bzw. Portfolio-Board nicht sinnvoll agieren.

Um die Gremien richtig nutzen zu können müssen wir ein paar Grundregeln beachten.

Kinder und Manager haben zumindest eines gemeinsam. Sie können sich nur 3 Dinge merken.

Bei Ihren Ausführungen als Projektmanager im Lenkungsausschuss empfehle ich Ihnen daher

  •          Die wichtigste Statusinformation
  •          Einen Entscheidungswunsch und
  •          Einen Mitwirkungswunsch

an das Management zu adressieren.

Achten Sie dabei immer darauf diese Kernbotschaften knapp und präzise zu formulieren, denn seit dem Jahr 2000 bis heute ist die Aufmerksamkeitsspanne bei uns Menschen von 12 auf 8 Sekunden gefallen. Der neuen Technik und dem neuen Lifestyle sei Dank.

Das heißt nach 8 Sekunden schweift der Zuhörer oder Betrachter ab, sofern nicht etwas Neues für sie oder ihn kommt. Übrigens, der Goldfisch hat seit eh und je 9 Sekunden Aufmerksamkeitsspanne und übertrifft uns seit Neuestem.

Jetzt komme ich zu den bereits angekündigten typischen Problemen. Erfahrungen aus meinen Projekten.

Berlin. Öffentliches Projekt. Bei öffentlichen Projekten ist die Trennung des Projektauftraggebers und der Gesellschafter oft sehr schwierig. Besonders die Governance-Organisation wird dadurch komplex. Die Anforderungen zu definieren ist in solch einem Konstrukt besonders schwer, ebenso wie das managen von Änderungen. Ein „reinregieren“ – dieses Verb klingt ja schon staatlich bzw. öffentlich – ist hier vorprogrammiert.

Südafrika. Ein Projekt bei einem Energiekonzern mit mehreren Konzernbereichen, welches zentrale Prozesse und IT-Systeme vereinheitlichen soll. Aufgrund der schieren Größe des Projektes sind mehrere externe Parteien erforderlich. Oft werden bei Großprojekten die Projektbüros gerne durch externe Beratungsunternehmen besetzt um den herausfordernden und neutralen Charakter zu unterstreichen.

Selbst als größter Auftragnehmer kann es schwer fallen einheitliche Gremiendefinitionen und Besetzungen zu prägen. Maximale Lösungszeiten von eskalierten Problemen auf den jeweiligen Eskalationsstufen zu vereinbaren ist oft ein Ding der Unmöglichkeit, aber erfolgskritisch.

Israel. Nochmals ein Energiekonzern mit mehreren Konzerntöchtern welche Ihre Beschaffungsorganisationen und Prozesse harmonisieren sollen. Ein weiteres Problem bei der Gremiennutzung ist die Entscheidungsfixierung und vor allem Entscheidungsdurchsetzung. Im Vorfeld zu Gremiensitzungen vorsozialisierte Entscheidungsalternativen und Entscheidungen werden oft nach erfolgter Sitzung wieder in Frage gestellt bzw. nicht durchgesetzt. Hier ist der kulturelle Einfluss prägend und aussteuernd. Entscheidungsfindungen können ein Vielfaches dauern.

Bonn. Eskalationsebenen sind bei Auftraggeber und Auftragnehmer nicht gespiegelt, das heißt eine unterschiedliche Anzahl an Hierarchieebenen ist vorhandenen. Probleme sind vorprogrammiert.
Ein weiteres Problem entsteht durch leider häufige Aussage und Umsetzung von „ein internes Projekt muss auch ohne LA funktionieren“. Wie soll das gehen?!

Damit möchte ich mit den typischen Problemen abschließen.

Welche 3 Kernbotschaften sollten Sie heute mitnehmen.

  1. Wir müssen die Unterschiede zwischen Lenkungsausschuss und Steuerungsgremium verstehen und auch immer die beiden Gremienarten erkennen und
  2. aktiv gestalten.
  3. Gerne Kontakt mit mir aufnehmen für aktiven Austausch.