Communication Principles in a Project

The first hours or at least days within a project do shape most of the ongoing communication in a project or program. In other words: if you do not or too late define communication principles in a project you will need to cope with issues in a later stage.

All soft topics like usage of mobile phones or laptops during meetings, respect between each other, listening to colleagues, confirm understanding, participation by all in meetings, avoid mails but call instead, and so on and so forth are topics which are often more easy to follow than the individual behavior in following topics. Therefore guidance should be given.

A set of my standard communication set up in projects from day 1 onwards as an example below.

 

I would like to ask you to follow these communication principles:

To minimize our mail traffic and an easier organization of our mailboxes we should agree on the following rules:

  • Only send mails towards the team members who need the information!
  • Sounds funny, meant is: avoid big distribution list without need! (same with copy!)
  • As long as we are working on drafts or on finalization of templates the drafts are only send around the nominated team
  • Often big copy distribution lists in mails are used for escalation of safety reasons, in case this is needed: Please contact and inform the Program Manager respectively the needed team member before. The Stream Leads are asked to design a workaround for internal escalation handling in their streams.
  • We agree that the work of all of us is very important for this program! For that reason only mails with a critical timeline are marked as urgent.
  • Mails with a critical impact for the program content have to be marked with URG at first.
  • To avoid overload the capacity of our mail server we send links where ever it is possible
  • Last but not least: Don’t bury the needed information’s in mail chains …

 

Mail naming convention

  1. All Mails have to be marked with the kind of information is given with the e-mail
  • INF: Information; an information is given to the addressees, no action required
  • ACT: Date, Action; and action is required by the addressee
  • DEL: Delivery; a required action is delivered
  • URG: urgent information’s start with this prefix
    e. g. URG: DREAM: SP01: … – see also file naming convention
  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

 

Document naming convention

All documents in the program are named as followed:

  1. Date (yyyymmdd)
  2. Project Name (DREAM) and sub project number (e. g. SP01)
  3. Document name
  4. Version (drafts V 0.1 ff; finalized versions V 1.0 ff)

E.g.: 20170220_DREAM_WP01_name convention_V 0-1.doc

The four elements are separated by an underscore.

 

All documents which have been reviewed follow this naming convention:

  1. <Name of Original Document>
  2. Rev<Initials of Reviewer>
  3. Date (yyyymmdd)
  4. g, 20170220_DREAM_WP01_name convention_V 0-1_RevMW_20170307.doc

 

Meeting Agenda

Effective meetings are always a challenge. There are many guidelines and checklist available for meetings. But up to now I have not found a good template for an effective meeting agenda.

In my daily usage I identified the need for two different agenda formats depending on the length of the meeting or better the number of agenda topics.

Having a telco I always use following simple format (in case not many topics need to be covered) since years:

INITIAL SITUATION/AUSGANGSSITUATION

  • Project status needs to be reported to steerco until Friday 12:00 CET

PREPARATION NEEDED / ERFORDERLICHE VORBEREITUNGEN (including owner)

  • Please update your work packages until Thursday 10:00 CET Server Link (ALL)
  • Please update action items status / resolution Server Link (ALL)
  • Update reporting template (ML)

AGENDA

  • Review interface issues between work packages (MW)
  • Align on action items across work packages (MW)
  • Align on Team Discussions items on project server (ML)
  • Issues and risks to be aligned on (ML)

RESULTS EXPECTED OF THE MEETING/ ERWARTETE ERGEBNISSE DES MEETINGS

  • Aligned view on the project status

NEXT STEPS AFTER THE MEETING/ NÄCHSTE SCHRITTE IM NACHGANG ZUM MEETING

  • Report to be consolidated (ML)
  • Report to be reviewed and send to steerco (MW)

 

For face2face workshops or long lasting telcos I prefer using following format also for many years:

Berlin, Hauptstr. 14-16, 1.OG, Room E1.15a, Monday 05. Feb 2018 – CMO FMO Big Picture
Goal: Common understanding of CMO and FMO Big Pictures and related activities
Approach: Time Boxing
Preparation: Presentation: Link on Server
Materials: 2 beamers, moderation suitcase
Time (CET) Topic Host Input and preparation needed / Owner Result expected / Owner  Attendees 
09:30 – 10:00 Introduction and target of meeting MW  Introduction – no preparation needed  All  All
10:00 – 10:30 CMO Picture Overall  LI  Slide deck / LI Common understanding of the CMO  All
10:30 – 10:45 Break        All
10:45 – 12:45 CMO / FMO INM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and UA
12:45 – 13:30 Lunch break in restaurant        All
13:30 – 14:15 CMO / FMO PRM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and AB
14:15 – 15:00 CMO / FMO CHM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and SE
15:00 – 15:30  CMO / FMO CFM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and ME
15:30 – 15:45 Coffee Break       All
15:45 – 16:15 CMO / FMO CPM  LI  Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS KE, CS, MA, UA and KL
 16:15 – 17:00 Wrap up and next steps  MW   Action item log updated. / MW

Work package descriptions amended. / work package owners

Steering Board Decision preparation / LI

 All

 

Projektleiter im Jahre 2030

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

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.

Working Out Loud

Working Out Loud ist besonders für die Arbeit in Projekten geeignet. Sie ist keine klassische Methode, sondern beansprucht für sich eine Lebenseinstellung zu sein – mit verbundenen praktischen Techniken. Die Elemente sind: Arbeit sichtbar machen und verbessern, Beiträge leisten, soziales Netzwerk aufbauen und zielgerichtet zusammenarbeiten.
 
Working Out Loud ist eine aus den USA stammende Methode, welche besonders für Mitarbeiter in Projekten geeignet ist. Initialer Vater der Idee war Bryce Williams. John Stepper hat daraus geschickt eine Bewegung generiert. Sie schwappt gerade über den Ozean und gewinnt neue Anwender in Deutschland. Sie denkt weiter. Sie ist keine klassische Methode, sondern beansprucht für sich eine Lebenseinstellung zu sein – mit verbundenen praktischen Techniken. Diese Lebenseinstellung führt auch zu gelebten Werten die in dieser Kombination nicht alltäglich sind. Ähnliche Ansätze trägt auch Austin Kleon in Show Your Work vor.
 
Die fünf Kernelemente von Working Out Loud sind (workingoutloud.de):
 
  • Arbeit sichtbar machen — Zwischenergebnisse, veröffentlichen,
  • Arbeit verbessern — Querverbindungen und Rückmeldungen helfen, Deine Ergebnisse kontinuierlich zu verbessern,
  • Großzügige Beiträge leisten — biete Hilfe an, anstatt Selbstdarstellung,
  • Soziales Netzwerk aufbauen — so entstehen breite interdisziplinäre Beziehungen, die weiterbringen,
  • Zielgerichtet zusammenarbeiten — um das volle Potenzial der Gemeinschaft auszuschöpfen.

Einführung in WOL

Working Out Loud ist besonders für die Arbeit in Projekten geeignet. Sie ist keine klassische Methode, sondern beansprucht für sich eine Lebenseinstellung zu sein – mit verbundenen praktischen Techniken. Die Elemente sind: Arbeit sichtbar machen und verbessern, Beiträge leisten, soziales Netzwerk aufbauen und zielgerichtet zusammenarbeiten.

Die Anwendung in einem Konzern wie T-Systems bei paralleler Anwendung von klassischem Projektmanagement wird dargestellt.

Inhalt sind praktische Beispiele der Anwendung, die Erfolgskriterien des Ansatzes und dessen Hürden in einer Projektorganisation vor.

Working Out Loud ist eine aus den USA stammende Methode, welche besonders für Mitarbeiter in Projekten geeignet ist. Initialer Vater der Idee war Bryce Williams. John Stepper hat daraus geschickt eine Bewegung generiert. Sie schwappt gerade über den Ozean und gewinnt neue Anwender in Deutschland. Sie denkt weiter. Sie ist keine klassische Methode, sondern beansprucht für sich eine Lebenseinstellung zu sein – mit verbundenen praktischen Techniken. Diese Lebenseinstellung führt auch zu gelebten Werten die in dieser Kombination nicht alltäglich sind. Ähnliche Ansätze trägt auch Austin Kleon in Show Your Work vor.

Die fünf Kernelemente von Working Out Loud sind (workingoutloud.de):

  1. Arbeit sichtbar machen — Zwischenergebnisse, veröffentlichen,
  2. Arbeit verbessern — Querverbindungen und Rückmeldungen helfen, Deine Ergebnisse kontinuierlich zu verbessern,
  3. Großzügige Beiträge leisten — biete Hilfe an, anstatt Selbstdarstellung,
  4. Soziales Netzwerk aufbauen — so entstehen breite interdisziplinäre Beziehungen, die weiterbringen,
  5. Zielgerichtet zusammenarbeiten — um das volle Potenzial der Gemeinschaft auszuschöpfen.

Working Out Loud in einer Projektsteuerungsorganisation

Wie funktioniert nun eine Anwendung in einem Konzern wie T-Systems unter Anwendung von klassischen Projektmanagement-Ansätzen. Widerspricht sich dies nicht? Mitarbeiter der Konzerne ThyssenKrupp, Robert Bosch und auch T-Systems praktizieren diese Einstellung und Techniken.

„Working Out Loud“ bedeutet, die eigene Arbeit zu „veröffentlichen“, Fortschritte, Probleme und Fehler zu berichten und darüber in Austausch mit anderen Kollegen zu gehen, damit alle von dem Gelernten partizipieren. Also nichts Neues denkt man spontan?! Eine kombinierte Anwendung der Kernelemente des Working Out Loud Ansatzes erfordert Disziplin, Offenheit und Konsequenz. 

Wie geschieht dies in der Praxis im Projekt?

Der Austausch im „eigenen Saft“ das heißt im eigenen Projekt reicht nicht. Ein Zugehen auf zentrale Stellen wie Tool- oder Prozessverantwortliche oder im besten Falle auch auf andere Projekte ist eine erste Grundvoraussetzung. Auch mit Stellen, welche oft nicht sehr beliebt sind wie zentrale Qualitätsmanagementeinheiten, Projektmanagementhandbuch-Verantwortliche oder Tool-Owner ist erforderlich. Ein intensiver Austausch über Zielsetzung, Anwendung und Lösung der anstehenden Herausforderung mit diesen ist ein Muss. Ich habe dies konsequent gelebt für mein aktuelles Projekt in dem wir ein nicht dem Unternehmensstandard entsprechenden Fortschrittsgrad und Forecast-Prozess und -tool aus besonderen Umständen entwickeln mussten. Bereits das Teilen von Mikroergebnissen mit auch nicht (direkt) betroffenen Projektkollegen hebt ungeahnte Potenziale. Das Einbinden, von Stakeholdern wie Auftraggeber, Nutzer, Richtlinienverantwortliche ist gewohnte Praxis, hebt aber nur teilweise das Potential.

Der Ansatz geht weiter als das bisher Dagewesene. Eine Vernetzung auch außerhalb des Konzerns zum Austausch von Ideen ist zwingend erforderlich. Denn ansonsten leidet die Effizienz und Effektivität jedes Vorhabens. Der Prozess, die Spezifikation, das Tool, die Schulung und der Rollout war in noch nie dagewesenen drei Wochen erfolgt. Bereits zwei Monate nach der Einführung wurde dann im Sinne „Beiträge an die Gemeinschaft zu leisten“ das Geschaffene bei der alljährlichen konzernweiten weltweiten Projektmanager-Community vorgestellt und als Good Practice definiert. Ein bis dahin in dieser Zeitspanne nie erreichter Abschluss. Genau genommen ist nicht nur die Schnelligkeit, sondern auch das „Überhaupt“ (abseits von Standardprozessen und Tools) ist bereits ungewöhnlich. Working Out Loud öffnet neue Horizonte und bringt eine frische Lebendigkeit und Interaktivität in und rund um die Projekte. Und sogar rund um Konzerne.

Selbst in großen Konzernen ist dieser „Kombi-Ansatz“ Working Out Loud aus bereits bekannten Ansätzen anwendbar und trägt Früchte über das einzelne Vorhaben hinaus.

Der Autor stellt an weiteren praktischen Beispielen die Anwendung, die Erfolgskriterien des Working Out Loud Ansatzes und auch dessen Hürden in einer Projektsteuerungsorganisation vor.

Aktive Teilnahme Arbeitsgruppe „WOL mit Konzernsicherheit und NDA“

Wollen Sie aktiv in einer Arbeitsgruppe mitmachen zum Thema:
„Working Out Loud mit Konzernsicherheit und NDAs“

Dann nehmen Sie bitte mit mir Kontakt auf.

Präsentation

Im Sinne des WOL habe ich die Präsentation vom PM-Forum Version 3.0 wieder zur Kommentierung freigegeben.
Besten Dank für alle bisherigen Hinweise zur Version 1.0 und 2.0!

 

How to measure team morale?

There are multiple ways to gather the team morale in project teams. I am using following approach for a few years now with reliable and sound results.

There is a systematic way in doing so by gathering „SmileyPoints“ via an online survey tool. Examples for free tools are kwiksurveys.com or the free version of surveymonkey.com. Google Forms does not allow easy embedding of graphics which is needed in our survey approach here.

Questions to gather in the survey are:

  1. “How happy are you being on the program/project?” Then the below picture should be attached to this question.
  2. “What can Program / Project Management do to improve?”
  3. “What can you do yourself do to improve?”
  4. “Rumor Box: If there are rumors around and you have any questions related to these please let us know here to clarify.”

In larger programs you may add a question to identify the participant’s team assignment to be able to give indication on the discrepancies between the different teams within the program.

The survey should be run every second week in case of a longer lasting projects or programs. It can be a good trend indication during the project life cycle. The minimum participation of project members should exceed at least 10% of all project team members. Less will not be representative. For smaller teams a higher minimum participation ratio must be achieved.

The average and the standard deviation of all results of responses to question number one gives you a clear indication on the team morale within the program or project team.

The higher the standard deviation of all values to question one the more obvious are
– a lack of communication within the team
(especially from top to down and bottom to up)
– roles and responsibilities not well defined or not transparent to the team and
– the scope not well defined or not transparent – at least to the extended team

The lower the average value of the results to question one is the less attractive is the project for the team members. Therefore the enthusiasm being part of the project is lower too. In very critical project situations (e. g. work life balance not achievable due to work load) the average tends to be low.

Now the question comes up of there is a *correlation between standard deviation and average”? Not really in all instances. The standard deviation should be low in a well-organized program. In the same over-worked organization if such things as structures, roles and responsibilities, communication channels, scope are well defined and transparent to the team the standard deviation should be still low.

The next questions is what is low and what is high”? A good one! Experience shows that values between +2 and +4 as an *averageare very common for projects in good shape. Of course there is a tendency for new joiners in a project to rate their personal happiness in areas of +6 to +10. These artifacts need a critical mass of responses to balance out.

This does not support the hypothesis that a new project with new team does automatically mean a good SmileyPoint average value. The team as a whole is well observing all team quality criteria before providing their SmileyPoints and in average the rating will be again to the “real” value.

On the other end of the SmileyPoint scale low average values as -6 to -2 indicate projects which are in a turnaround mode or at least in a need to turnaround. Immediate actions need to take place.

For standard deviation following pattern can be identified. Values of 6 show massive deficit of structures implemented, missing role definitions or at least transparency on it. Criteria e) to i) from below listing do impact the standard deviation up to my experience. Programs in a good shape show a standard deviation of less than 3. 

Of course a survey like this will not replace individual talks and interviews but it gives you a very precise supporting evidence of your findings in conversation or at least an initial feeling in case you did not have any contact to the program at all.

In a next posting I will list a couple of elements and ideas on what to implement to improve the SmileyPoints in your team.

Your comments and participation

I would like to receive as many as possible comments with values for
– average and
– standard deviations
– number of participants out of total number of team members

from some of your projects and programs. Especially helpful would be if you can add a typical auditors or your personal rating on the same scale from below on following topic clusters:
a. team morale within the extended team
b. program financials in good shape and transparent to the project management
c. infrastructure well established (e. g. printers, office space)
d. right skills on board
e. architecture and solution well defined
f. methodologies applied properly
(e. g. project planning, issue and risk management)
g. roles and responsibilities and structure well defined
h. scope and acceptance and completion criteria well defined and transparent
i. governance well defined and in place

So a typical answer could look like:
Average: +5, Standard Deviation: 2, a) +5 b) +4 c) +3 ….

Any other comments are also more than welcome.