Agiler Wirbel?!

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.

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.

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.
 

Einführung in WOL

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 (ursprünglich abgerufen von 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.

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 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!

 

Vorsprung durch Frühwarnung im Projekt – Teamstimmung als Indikator

– Methodischer Umgang mit Emotionen im Projekt –

Summary

Als Projektportfoliomanager möchten Sie in allen Ihren Projekten vollständige Projektaudits vermeiden, um mögliche Abweichungen zu identifizieren. Sie können eine sehr einfache Umfrage verwenden, um Überraschungen zu vermeiden.

Als Projekt- oder Programmmanager möchten Sie Ihr aktuelles Vorhaben auf sehr einfache Weise mit früheren Projekten vergleichen.

Es gibt mehrere Möglichkeiten, die Teamstimmung in Projektteams zu festzuhalten. Ich verwende seit einigen Jahren folgenden Ansatz mit zuverlässigen und soliden Ergebnissen.

Dies geschieht systematisch durch das Sammeln von „SmileyPoints“ über ein Online-Befragungstool. Beispiele für kostenlose Tools sind kwiksurveys.com, die kostenlose Version von surveymonkey.com oder Google Forms.

Fragen, die in der Umfrage gesammelt werden sollen

  1. „Wie glücklich bist du über das Programm/Projekt?“ Dann sollte das obige Bild dieser Frage beigefügt werden.
  2. „Was kann Programm-/Projektmanagement zur Verbesserung beitragen?“
  3. „Was kannst du selbst tun, um dich zu verbessern?“
  4. „Rumor Box: Wenn es Gerüchte gibt und du irgendwelche Fragen dazu hast, lass es uns bitte hier wissen, um es zu klären.“

In größeren Programmen können Sie eine Frage hinzufügen, um die Teamzuordnung des Teilnehmers zu identifizieren, um Hinweise auf die Unterschiede zwischen den verschiedenen Teilteams innerhalb des Programms geben zu können.

Die Umfrage sollte jede zweite Woche durchgeführt werden, wenn es sich um längerfristige Projekte oder Programme handelt. Es kann ein guter Trendindikator während des Projektlebenszyklus sein. Die Mindestbeteiligung der Projektmitglieder sollte mindestens 10% aller Projektteammitglieder überschreiten. Weniger wird nicht aussagekräftig. Für kleinere Teams muss eine höhere Mindestteilnehmerzahl erreicht werden.

Ergebnisinterpretationen

Der Durchschnitt (Mittelwert) und die Standardabweichung aller Ergebnisse der Antworten auf Frage Nummer eins gibt Ihnen einen klaren Hinweis auf die Teamstimmung innerhalb des Programmes oder des Projektteams.

Je höher die Standardabweichung aller zu hinterfragenden Werte ist, desto offensichtlicher sind:

  • mangelnde Kommunikation innerhalb des Teams
    (insbesondere von oben nach unten und von unten nach oben)
  • Rollen und Verantwortlichkeiten, die nicht klar definiert oder für das Team nicht transparent sind und
  • der Umfang ist nicht klar definiert oder nicht transparent – zumindest für das erweiterte Team.

Je niedriger der Mittelwert der zu befragenden Ergebnisse ist, desto weniger attraktiv ist das Projekt für die Teammitglieder. Daher ist auch die Begeisterung für das Projekt geringer. In sehr kritischen Projektsituationen (z. B. aufgrund der Arbeitsbelastung nicht erreichbare Work Life Balance) ist der Durchschnitt tendenziell niedrig.

Nun stellt sich die Frage, ob es einen „Korrelation zwischen Standardabweichung und Mittelwert“ gibt? Nicht wirklich in allen Fällen. Die Standardabweichung sollte in einem gut organisierten Programm gering sein. In der gleichen überlasteten Organisation, wenn Dinge wie Strukturen, Rollen und Verantwortlichkeiten, Kommunikationskanäle, Umfang gut definiert und für das Team transparent sind, sollte die Standardabweichung noch gering sein.

Die nächste Frage ist, was ist niedrig und was ist hoch“? Eine gute! Die Erfahrung zeigt, dass Werte zwischen +2 und +4 als Durchschnitt bei gut funktionierenden Projekten sehr häufig sind. Natürlich gibt es die Tendenz, dass neue Teammitglieder in einem Projekt ihr persönliches Glück in Bereichen von +6 bis +10 bewerten. Diese Artefakte benötigen eine kritische Masse an Reaktionen, um sich auszugleichen.

Dies unterstützt nicht die Hypothese, dass ein neues Projekt mit neuem Team automatisch einen guten SmileyPoint Durchschnittswert bedeutet. Das gesamte Team beachtet alle Qualitätskriterien des Teams gut, bevor es seine SmileyPunkte vergibt, und im Durchschnitt wird die Bewertung wieder auf den „realen“ Wert gebracht.

Am anderen Ende der SmileyPoint-Skala zeigen niedrige Durchschnittswerte von -6 bis -2 Projekte an, die sich in einem Turnaround-Modus befinden oder zumindest einen Turnaround benötigen. Es müssen sofortige Maßnahmen ergriffen werden.

Für die Standardabweichung kann folgendes Muster identifiziert werden. Werte von 6 zeigen ein massives Defizit an implementierten Strukturen, fehlende Rollendefinitionen oder zumindest Transparenz darüber. Die Kriterien e) bis i) von unten nach oben beeinflussen die Standardabweichung nach meiner Erfahrung. Programme in gutem Zustand zeigen eine Standardabweichung von weniger als 3.

Natürlich ersetzt eine solche Umfrage keine Einzelgespräche und Interviews, aber sie gibt Ihnen einen sehr präzisen, unterstützenden Beweis für Ihre Ergebnisse im Gespräch oder zumindest ein erstes Gefühl, falls Sie überhaupt keinen Kontakt zum Programm hatten.

In einem anderen Beitrag werde ich ein paar Elemente und Ideen auflisten, was zu implementieren ist, um die SmileyPoints in Ihrem Team zu verbessern.

Ihre Kommentare und Teilnahme zur Verbesserung von SmileyPoints

Wenden Sie SmileyPoints aktiv in Ihren Projekten an!

Ihre Kommentare und aktive Teilnahme sind gewünscht. Beides können Sie in folgender Umfrage hinterlegen und Sie werden auf Wunsch über neue Erkenntnisse informiert.

Diese Werte sollten Sie erfassen:

  • Mittelwert- und
  • Standardabweichungen
  • Anzahl der Teilnehmer von der Gesamtzahl der Teammitglieder

aus einigen Ihrer Projekte und Programme. Besonders hilfreich wäre es, wenn Sie einen Auditor oder Ihr persönliches Rating auf der gleichen Skala von unten zu folgenden Themenclustern hinzufügen könnten:
a. Teamstimmung innerhalb des erweiterten Teams
b. Programmkostensituation in guter Verfassung und transparent für das Projektmanagement.
c. Infrastruktur gut ausgebaut (z. B. Drucker, Büroräume)
d. Richtiges Fähigkeiten/Personal an Bord
e. Architektur und Lösung gut definiert
f. ordnungsgemäß angewandte Methoden
(z. B. Projektplanung, Issue- und Risikomanagement)
g. Rollen und Verantwortlichkeiten und Struktur klar definiert
h. Leistungsumfang und Akzeptanz- und Abschlusskriterien klar definiert und transparent
i. Governance klar definiert und etabliert

Bitte nutzen Sie dieses Formular, um Ihr Feedback zur Verbesserung von SmileyPoints einzureichen.

Hier ein Slide Deck zum Thema.

Dieser Beitrag wurde bereits am 23.07.2011 auf GooglePlus veröffentlicht.