Projektmanagement-Begriffe

• Projekt
  Die voraussichtliche Definition von Projekt nennt im Wesentlichen die gleichen Bestandteile wie meine Definition im PM-Wörterbuch mit dem Unterschied, dass ein Schwerpunkt auf Prozesse gelegt wird: “A project is a unique set of processes consisting of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective.”

• Projektmanagement
  Ähnliches gilt für die Definition von Projektmanagement: “Project management is the application of methods, tools, techniques and competencies to a project. Project management includes the integration of the various phases of the project life cycle … and is performed through processes.“. Auch hier wird gegenüber der Definition im PM-Wörterbuch der Prozesschwerpunkt betont.

• Wissensgebiet
  Wie erwartet wurde der Begriff Wissensgebiet in subject group geändert.

PMBOK^® Guide

Die Wissensgebiete des PMI wurden scheinbar übernommen und das Gebiet Stakeholder hinzugefügt. Im PMBOK^® Guide 5th edition ist diese Änderung bereits wieder “rückübernommen” worden. Schauen wir uns die Änderungen am Prozessmodell gegenüber dem PMI im Detail an:

1. Integration – Der Prozess Collect Lessons Learned ist neu in der ISO-Norm.
2. Stakeholder – analog dem PMI
   
3. Scope – Collect requirements wurde leider von der ISO nicht übernommen und Define activities aus dem Wissensgebiet Time des PMI hierhin übernommen.
4. Resource – Establish project team und Acquire project team wurden nicht in die ISO-Norm übernommen, dafür gibt es in der ISO nun den Prozess Control resources und der Prozess Estimate activity resources ist vom Wissensgebiet Time in das Wissensgebiet Resource der ISO gewandert.
5. Time – Define activities ist wie gesagt in das Wissensgebiet Time gewandert.
6. Cost – keine Änderungen
7. Risk – Plan risk management entfällt in der ISO-Norm und qualitative und quantitative Risikoanalyse wurden zu Assess risks zusammengeführt. Neu ist der Prozess Treat Risks!
8. Quality – keine Änderungen
9. Procurement – Close procurements ist in der ISO-Norm leider entfallen und stellt für mich damit ein loses Ende eines Projekts dar.
10. Communication – Identify stakeholders entfällt in der neuen Norm, wobei dies auch eher eine Aktivität als ein Prozess ist, allerdings halte ich den Entfall von Manage stakeholder expectations für ungünstig.

Darüber hinaus wurden viele Prozesse umbenannt und ggf. verbergen sich hier einige inhaltliche Änderungen.

DIN 69901

Während meiner Mitwirkung an der deutschen Projektmanagement-Norm hatte ich einige Änderungsvorschläge angemerkt, mich aber nicht durchsetzen können. Auf der einen Seite verschafft es mir natürlich etwas Befriedigung dass die Änderungen durch die ISO-Norm unterstützt werden, auf der anderen Seite wäre es schöner gewesen sich den Schlenker gleich zu sparen. Konkret:

1. Statt Projektmanagementphasen und Prozess-Untergruppen haben sich Prozessgruppen und Themengebiete als Begriffe durchgesetzt.

2. Aus den acht Prozessen in der Abschlussphase der DIN sind nun noch zwei vorhanden, insbesondere ist der DIN-Prozess zur Würdigung der Leistungen aller Beteiligten aus meiner Sicht nur eine Aktivität gewesen. Allerdings wurde ein lessons-learned-Prozess in die ISO-Norm aufgenommen was wiederum Sinn macht.

(Inter)national Competency Baseline

Die Standards von IPMA und GPM werden voraussichtlich um ein Prozessmodell angereichert werden.

Weiteres bei der ISO

Lt. Projekt Magazin werden derzeit Normen in Bereichen Portfoliomanagement und PM-Governance initiiert und Normen zum Programmmanagement und einzelner PM-Aspekte angedacht.

Insgesamt wird sich in den nächsten Jahren ein Trend zur Vereinheitlichung von Standards und Normen zeigen, wie er bereits mit dem Start des ISO 21500-Projekts absehbar war. Wenn ich mehr Details habe, werde ich das Thema wieder aufgreifen.

Aufgrund der Unterschiede der Prüfungsinhalte sind Höherzertifizierungen direkt auf Basis von PRINCE2-Zertifikaten derzeit nicht geplant, allerdings darf man als Praxisnachweise bald auch Projekte auf Basis der PRINCE2-Methodik einreichen. Derzeit läuft ein Pilotprojekt für die Brückenzertifizierung in Polen, wobei lt. Herrn Wagner (Forschungsvorstand der GPM) die Einführung der Brückenzertifizierung allerdings nicht sicher ist (vgl. Kommenentar zu diesem Posting).

Inhaber der neuen PRINCE2-Professional-Zertifizierung dürften ebenfalls die Brückenzertifizierung nutzen können, da sie als Zugangsvoraussetzung für die Professional-Prüfung bereits den PRINCE2-Practicioner mitbringen müssen.

Verwenden Sie die folgende Präsentation, um vielleicht doch ein Umdenken auszulösen mit dem dringenden Hinweis, sich das Video sicherheitshalber alleine anzusehen wg. Risikos einer Palastrevolution ,-)

Hinweis: Ein Klick auf das Bild ruft das Video bei YouTube auf.

Im Gegensatz zu den anderen beiden PRINCE2-Zertifizierungen gibt es kein Training für den Professional. Stattdessen durchläuft man ein 2 1/2-tägiges Assessment Center (AC) mit möglichst realistischen Projektumgebungen, innerhalb derer sich Kandidaten beweisen können. Währenddessen sammeln die Prüfer Hinweise auf die Qualifikation des Kandidaten, ergänzt um Interviews, Einzelaufgaben und Essays.

Zwischen 6 und 16 Kandidaten durchlaufen das AC jeweils parallel, gemessen werden 19 Kompetenzkriterien. U.a. gehören die Vorbereitung eines Business Cases, Soft Skills, Produktbasierte Planung und Lessons Learned in den Bereich der Kompetenzkriterien. Voraussetzung für das AC ist eine Practicioner-Zertifizierung und die sichere Beherrschung der englischen Sprache.

Design Thinking wurde im 1. Workshop von Ahmet Emre Acar über Spielkarten mit Konzepten aus der Welt des Design Thinkings vermittelt. Ziel war es in Gruppen möglichst viele eigene Vorgehensweisen rund um die Analyse von Startup-Ideen zu sammeln. Während der Diskussion der Vorgehensweisen wurde das Verständnis für Design Thinking aufgebaut und ich hoffe, dass die Karten noch wie versprochen im Netz veröffentlicht werden.

Der zweite Workshop von Stefan Haas und Stefan Wolpers drehte sich um den schnellen Einstieg in Scrum (vgl. Posting von Stefan Haas: We Bring the Post-its – You Do the Learning). Dabei ging es um die Entwicklung einer neuen Plattform, um Leute, Ideen und Kapitel für die Förderung von Innovation und zur Gründung von Startups zusammenzubringen. Eine umfangreiche Materialsammlung incl. Scrum Guide waren an den Wänden aufgehängt bzw. ausgelegt, darunter auch ein Paper prototyping helpder kit, um User Interfaces mit Schere und Kleber basteln zu können.

Nach einer kurzen Einführung mussten innerhalb von Teams Scrum-Rollen verteilt werden, unterstützt durch vorgefertigte Rollenbeschreibungen. Der CEO, u.a. für die Vision zuständig, konnte in meinem Team u.a. auf die Ergebnisse der Design Thinking-Session bauen. Glücklicherweise war einer seiner Teamkollegen aus dem 1. Workshop auch gleich als Product Owner im 2. Workshop an Bord.

So standen zunächst leicht verwirrte “Teammitglieder” im Raum, die aber recht schnell in funktionierenden 20-Minuten-Sprints arbeiteten mit Erstellung eines Product Backlogs, Erstellung eines UI mit dem Prototyping Kit und einem CEO, der kräftig außerhalb des Workshops auf dem Camp neue Teammitglieder rekrutierte.

Letzendlich kamen sogar einige konkrete Ergebnisse heraus trotzdem die Sprints sehr kurz waren und die Teilnehmer zumeist noch nicht mit Scrum gearbeitet hatten. Da sich mindestens ein Scrum-Experte pro Team fand war das geringe Vorwissen kein großes Hindernis. Dafür war der Aufbau eines Teams mit den geeignetsten Rollen eine Herausforderung. Für die Umsetzung des Product Backlogs musste man sich eine Organisation schaffen, in der die notwendigen Skills vorhanden waren bei einer begrenzten Anzahl von Teammitgliedern. Die Basis dafür war das Meddlers Game von Jurgen Appelo.

Für mich war überraschend, dass sich schnell funktionierende Teams bildeten trotz des meist unbekannten Scrum-Frameworks und viele Leute außerhalb des Workshops zur Teilnahme gewonnen werden konnten. Selbige hatte noch weniger Einarbeitung, empfanden den Workshop aber trotzdem als spannend und lehrreich.

Die Spielziel, die Generierung von “Insights”, d.h. Erkenntnissen darüber wie Scrum, Teams und das Spiel funktionieren fand ich äußerst gelungen. D.h. es ging weniger darum gemeinsam schnell ein minimum viable product zu schaffen, sondern mehr darum, über die Zusammenarbeit zu lernen.

Hilfreich wäre es gewesen kein Überangebot von Einstiegsinformationen bereitzustellen dessen Zweck sich teilweise erst durch Nachfrage erschloss. Viel wichtiger finde ich es mit wenigen klaren Informationen, z.B. organisiert über eine Mindmap zu starten und zusätzliche Informationen in der Hinterhand bereitzuhalten. Eine Verlängerung der Sprints von 20 auf 30 Minuten würde etwas die Hektik reduzieren, ggf. wären sogar anfänglich 45 Minuten sinnvoll mit einer späteren Verkürzung. Dafür hätte ich gerne einen ganzen Tag statt nur einen Nachmittag investiert.

Auf jeden Fall habe ich viele interessante Leute kennengelernt und einige wichtige Erkenntnisse über die Skalierung von Scrum-Organisationen für mich mit nach Hause genommen und werde Gamification sicher in Zukunft häufiger einsetzen.

Bildquelle: flickr, VFS Digital Design

Es ist ein bekannter Konflikt: Auf der Suche nach Praktikanten und Azubis findet man viele Jugendliche, deren Lernweg bis zum erfolgreichen Einstieg in die Kultur eines Unternehmens noch lang ist. Über das Blog von Jeff Sutherland, einem der Begründer von Scrum, bin ich gerade auf eduScrum gestoßen.

Die Idee Scrum in der Schule einzusetzen wird seit Oktober 2011 von Willy Wijnands und Jan van Rossum im Chemieunterricht am Ashram College in Alphen aan den Rijn in den Niederlanden umgesetzt. Die wesentlichen Aspekte sind:

• Teambildung
  Zunächst sprechen die Schüler über ihre Fähigkeiten, Softskills etc., danach bilden sie Vierergruppen mit dem Ziel, gemeinsam mehr Fähigkeiten an den Start zu bringen.

• Planung
  Statt Story Points gibt es ein Punktesystem in dem jeder Punkt 10 Minuten entspricht und es Aufgabe der Schülerteams ist, Zeitpläne aufzustellen. Die Schüler tendierten dazu den Frontalunterricht komplett durch ihre eigene Planung zu ersetzen, allerdings gehört der Umgang mit Änderungen auch zum Geschäft.

• Scrum Events
  Neben dem bereits erwähnten kleinen Planungsansatz wird jede Stunde durch ein “Daily Scrum” begonnen.

Das Feedback der Schüler ist hervorragend, insbesondere erkennen Sie die Stärken von eigenverantwortlicher Teamarbeit.

Aus meiner Sicht werden durch die längere Zusammenarbeit in Gruppen sowie den höheren Grad an Delegation Schwächen des klassischen Frontalunterrichts mit Gruppenarbeit kompensiert. Die Kompetenz der Schüler wird aus meiner Erwartungshaltung bezogen auf einen späteren Berufseinstieg deutlich höher sein, da viele Grundlagen der Zusammenarbeit in Unternehmen mit eduScrum besser gelernt werden.

Eine Domain haben sich die beiden Lehrer schon reserviert und werden später dort ihr Material veröffentlichen: eduscrum.nl.

• welche Vorteile PRINCE2 in Projekten bringt,
• wie Projekte sich unterscheiden,
• wie PRINCE2 für verschiedene Projekte adaptiert werden kann,
• wie PRINCE2 in Bezug zum Programm-Management steht und
• wie PRINCE2 sich zu Standards von APM und PMI sowie agilen Vorgehensweisen verhält.

Die gesuchten Autoren sollen natürlich tiefe PRINCE2-Kenntnisse haben, mehrfach PRINCE2 eingeführt haben und MSP sowie andere PM-Ansätze kennen. Interessenten mögen sich bis zum 30.05.2012 an Neil Glover wenden mit CV und einer Arbeitsprobe.

Gesucht werden Autoren mit sehr gutem Fachwissen bezüglich P3O, Management of Portfolios (MoP) und Management of Value (MoV) sowie Praxiserfahrung in den Bereichen PMO und P3O-Tools. Aber Achtung: Man muss zu den Projektmeetings nach England reisen.

Wer interessiert ist wird gebeten sich bei Neil Glover mit zum 28.05.2012 mittags melden mit CV und einer Arbeitsprobe.

Schneepflüge auf dem Flughafen Stockholm
© 2012 Stefanie Hofmann

Diesmal hat mir das Projekt Magazin mit dem Artikel Risiken der Agilen Software-Entwicklung reduzieren – Ein bisschen Wasserfall muss sein eine Steilvorlage geliefert. Aber fangen wir mit einem starken Argument an und schauen dann, wo der Artikel zu Recht mögliche Schwächen agiler Methoden anspricht und wie die Lösung in der agilen Welt ohne Anleihen aussieht.

Zuerst: Das Wasserfallmodell hat noch nie funktioniert! Zumindest wenn man dem Autor Winston Royce glaubt, der das Modell aufgebracht hat. Wie Eberhard Huber vor zwei Jahren gebloggt hat, zerlegt Royce das Wassermodell gleich in dem Artikel, in dem er es aufgebracht hat: “In my experience, however the simpler method [Wasserfallmodell] has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process [Iteratives Modell] listed.”.

Dank Eberhard grinse ich seit zwei Jahren jedesmal, wenn jemand “Wasserfallmodell” sagt. Die einzigen erfolgreichen reinen Wasserfallprojekte die ich kenne sind Projekte, die in 2 Arbeitspaketen (à 2 Wochen gedacht) oder weniger abgewickelt sind und damit eigentlich kaum auf dem Radar der Methodikdiskussionen erscheinen sollten.

6 Gründe für agilen Wasserfall?

Hier sind die aus meiner Sicht 6 relevanten Gründe des Artikels für das Aufmotzen von Scrum mit Wasserfallelementen oder um präziser zu sein, Elementen des klassischen Projektmanagements…denn mit Wasserfall hat der Artikel überhaupt nichts zu tun:

• Abhängigkeiten schlecht gemanaged
  Schwachpunkt: “Abhängigkeiten, z.B. zu einer Produktivumgebung werden in agilen Projekten mangels technischem Projektleiter ggf. vernachlässigt.”
  Antwort: Es ist der Job des Product Owners, die Konzeption und Weiterentwicklung eines Produkts zu treiben. Er ist der Nachfolger des Projektmanagers als Kommunikator in Scrum. Ob am Ende das Development Team die Abhängigkeiten klärt kann gewählt werden.
• Anforderungen werden depriorisiert
  Schwachpunkt: “Die Depriorisierung von Anforderungen durch neue wichtigere Anforderungen und das daraus folgende Risiko deren Nicht-Umsetzung wird dem Auftraggeber nicht ausreichen bewusst.”
  Antwort: Transparenz ist einer der wichtigsten Werte von Scrum und wieder ist es der Job des Product Owners dies zu managen. Dass einem klassischen Projektleiter dies durch einen Change Request aufgezwungen wird ist nicht schlecht, allerdings sollte der gesunde Menschenverstand in der agilen Welt für ein erfolgreiches Management solcher Situationen ausreichen.

• Unvollständige Konzepte
  Schwachpunkt: “Testen würde frühzeitig konzeptionelle Fehler aufzeigen.”
  Antwort: In jedem Sprint sollten die User Stories so wie sie fertig sind abgenommen werden. Somit werden unvollständige oder fehlende Anforderungen möglichst früh erkannt. Darüber hinaus werden Anforderungen meist über rollierende Planung schrittweise verfeinert, d.h. der komplette Scope eines Projektes existiert in grober Form im Backlog und wird dann verfeinert. Die Anforderungen werden zum letzten verantwortbaren Zeitpunkt verfeinert und somit viel Aufwand für Change Management gespart ohne schwerwiegende Beeinträchtigung aufgrund “vollständiger” Vorab-Konzeption.

• Burndown-Chart unvollständig
  Schwachpunkt: “Zeit- und Budgetvorgaben können aufgrund der Kürze von Burndown-Charts aus dem Blickfeld geraten.”
  Antwort: Wieder ist es der Job des Product Owners die Einhaltung oder Verletzung von Randbedingungen transparent zu machen. Über die Releaseplanung in Scrum sind das notwendige Werkzeug vorhanden. Die meisten Projektreportings sind so komplex, dass sich jede Nachricht erfolgreich vermitteln lässt unabhängig von den Fakten. Bei Burndown Charts liegt der Charme in der Einfachheit und der Reduzierung auf die wenigen wirklich wichtigen Fakten. Dieses Reporting wird dann auch gerne gelesen, wie Ken Schwaber immer wieder gerne mit Anekdoten in seinen Trainings belegt.

• Qualitätsrisiken
  Schwachpunkt: “Risiken da das Development Team ggf. Qualitätskompromisse eingeht, um fertige Features zeigen zu können.”
  Antwort: Lt. deutschem Recht sind Ergebnisse nach dem “Stand der Technik” abzuliefern, d.h. Nachbesserungen sind bei Bedarf ohne Mehrkosten einforderbar. Darüber hinaus ist wieder Transparenz gefordert. Das Risiko der Technical Debt besteht außerdem bei klassischen Projekten genau so wie bei agilen Projekten.

• Technologierisiken
  Schwachpunkt: “Neue Technologien werden dank niedriger Hürden zu schnell genutzt.”
  Antwort: Wieder eine Transparenz- und Abstimmungsfrage und damit keine Schwäche agiler Methoden.

Fazit

Der Artikel endet mit:

“Bei aller Begeisterung für agile Vorgehensweisen ist es gerade für unerfahrene Teams wichtig zu verstehen, dass bewährte Prozesse zur Einhaltung von Zeit und Budget ökonomisch sinnvoll sind. So kann ein agiles Projekt mit “etwas Wasserfall” nicht nur zur Zufriedenheit der Anwender, sondern auch in Zeit-, Budget- und Qualitätszielen umgesetzt werden.”

Den Satz würde ich so komplett streichen. Unerfahrene Teams werden bei jeder Methodik mit besonderen Risiken konfrontiert. Strenge Prozesse sind an der Stelle weniger die Heilung als Begleitung = Coaching, was wiederum der Job eines Scrum Masters ist.

Bei agilen Projekten wird als Rahmenbedingung das Sponsoring verwendet, d.h. nur noch eine von den früher verwendeten Randbedingungen Scope, Zeit und Budget wird eingeschränkt. Anstatt z.B. eine Scope in unmöglicher Zeit bei möglicherweise passendem Budget umsetzen zu wollen werden die unwichtigsten Features eben nicht mehr umgesetzt. Insbesondere werden 80% der Features von Softwareprodukten typischerweise von Kunden nicht genutzt. Grund dafür ist insbesondere die up-front-Spezifikation ohne angemessene Iterationen und Inkremente mit Einarbeitung von Kundenfeedback, d.h. genau die Medizin, die die Autoren der agilen Welt verabreichen wollen.

Sehr gut an dem Artikel ist der Hinweis auf das von Mike Cohn modifizierte Burn-Down-Chart, welches u.a. die Aufwände für Change Requests transparent macht.

Die genannten Schwächen der agilen Welt beruhen aus meiner Sicht darauf, dass die Product Owner-Rolle unterschätzt wird und unabhängig von der Methodik bzw. vom Framework immer noch Kommunikation der wesentlichste Erfolgsfaktor für Projekte ist. Wie einleitend erwähnt hat der Artikel auch keinen Bezug zum Wasserfallmodell, sondern bezieht sich auf agile Methoden mit einer Ergänzung durch klassisches Projektmanagement.
Insgesamt kann ich mich dem Artikel nicht anschließen und vermisse die notwendigen Primärquellen wie beispielsweise den Scrum Guide.

Ich hoffe mit diesem Posting Lösungen für die genannten Schwachpunkte angeboten zu haben und freue mich auf eine heiße Diskussion.

Angefangen hat alles 1948 im Buch Your Creative Power von Alex Osborne mit der Idee, einen Sturm der Ideen in den Gehirnen einer Gruppe zu entfachen und damit die besten Ideen zu produzieren. Immerhin ca. 80% der Menschen glauben das “Märchen” dass Experten seit 50 Jahren mit immer mehr Forschungsergebnissen widerlegt haben.

In der Basisform werden nacheinander in der Gruppe Ideen genannt, aber erst in einer späteren Phase bewertet. Darin liegt auch genau die Schwäche von Brainstorming: Während man versucht seine eigene Idee nicht zu vergessen hört man den Anderen auch nicht richtig zu. Trotzdem fühlen sich alle danach gut, denn in der Gruppe fühlen sich Menschen wohl und somit sieht man die Technik auch eher durch die rosarote Brille.

Eine Lösung liegt in der Lösung der durch Sequentialität bedingten Blockade durch Einführung von Parallelisierung, d.h. auf die Teilnehmer entwickeln ihre Ideen unabhängig voneinander und gleichzeitig. Die Forschung zeigt dass so durchweg mehr und bessere Idee entstehen. Ohne schriftliche Niederlegung der Ideen funktioniert es nicht und so kommt man bei den verschiedenen Spielarten des Brainwritings an:

• Brainwriting
  ist die Basisform verschiedener Methoden und fordert lediglich die schriftliche Niederlegung von Ideen und die Abtrennung der Bewertung in eine zweite Phase.

• Brainwriting-Pool
  • Ideen werden auf Karten notiert.
  • Fertige Karten werden rechtsum weitergereicht und vom Nächsten ggf. ergänzt bis sie wieder beim Autor ankommen.
  • Wenn man gerade keine Zeit hat können Karten durchgereicht werden.
  • Wenn man gerade keine Idee hat, kann man sich durchgesehene Karten nehmen, ergänzen und wieder in Umlauf bringen.

  Irgendwann ebbt die Aktivität ab und man hat seinen Ideenstapel für die Bewertung.

• Galeriemethode
  • Einführungsphase – Der Gruppenleiter stellt das Problem dar.
  • Ideenbildungsphase I – Jeder entwirft eine Lösungsskizze.
  • Assoziationsphase – Die Skizzen werden “aufgehängt” und von allen diskutiert.
  • Ideenbildungsphase II – Die Ergebnisse werden eingearbeitet.
  • Selektionsphase – Vorauswahl der besten Lösungen.

• Kartenabfrage
  Kartenabfrage und Pinnwandmoderation nutzen ähnliche Mittel wie Brainwriting-Pool und Galeriemethode. Diese beiden Methoden gefallen wir auf Anhieb am Beste.

Wenn ich eine aus Ihrer Sicht wichtige Methode ergänzen soll bitte ich um Hinweis.

• 45 Artikel von 1.050 sind in den Papierkorb gewandert, alle anderen geprüft und bei Bedarf redigiert worden.
• Alle Artikel sind jetzt geeignet verlinkt über einen Abschnitt “Weiterführende Informationen”. Von über 1.500 Kommentaren sind dabei ca. 600 in den Papierkorb gewandert, die diese Verlinkung bisher mehr schlecht als recht realisiert haben.
• An der Performance des Blogs habe ich ebenfalls gedreht, insbesondere durch den Rauswurf von YouTube und Verkleinern von Bildern. Sobald man YouTube-Videos in der Seite anzeigt lädt sie unglaublich langsam. So verweise ich nun mit Bildern auf YouTube-Content.
• Der Cache (varnish) lebt jetzt auch ein angenehmeres Leben. Denn bisher konnte man durch Runterladen der Podcasts über iTunes mit jeweils drei gleichzeitig geladenen Videos seinen gesamten bisherigen Inhalt verdrängen, d.h. alle Seiten und Bilder wurden dann langsam über die Blog-Software bereitgestellt. Jetzt klappt das auch mit dem Cache…return(pipe) bewirkt Wunder ,-)

Auf dem Wege möchte ich Ihnen zwei Tools ans Herz legen für die Optimierung von Webseiten: Google PageSpeed Online und WebPageTest, ebenfalls von Google.

Das erste Tool verrät einem einfach wie man seine Seite noch schneller ausliefern kann, z.B. durch kleinere Bilder etc. Die zweite Seite stellt einen möglichen zukünftigen Dienst von Google dar, der Seiten beschleunigt. Dabei werden die Seiten vom Server geladen, optimiert und dann an den Kunden über das weltweite Server-Netzwerk von Google ausgeliefert. D.h. der Service bietet sich an, wenn man keine Chance hat den Aufbau der eigenen Seiten zu verbessern.

Aktuelles Ergebnis: Für mein Blog lohnt es sich nicht da es ohnehin ab der zweiten Seite schneller ist als Google. Bestergebnis: 0.66 Sekunden!. Und darüber hinaus gibt es jeweils ein Video mit dem man das Ladeverhalten vergleichen kann:

Scrum wird hier auf die Teamebene und die darauf aufbauene Programmebene aufgeteilt sowie eine übergeordnete Portfolioebene hinzugefügt:

1. Teamebene (Stories)
   Scrum Teams, Team Backlogs, Sprints, Stories, Tasks/Spikes
2. Programmebene (Features)
   Vision, Roadmap, Produktmanagement, Program Backlog, Releaseplanung, Features
3. Portfolioebene (Epics)
   Portfolio Backlog, Epics, Architektur

Im Wesentlichen wird auf die Vorgängerversion des Scrum Guides gesetzt, denn das Backlog wird noch priorisiert statt geordnet und die Teamgröße liegt noch bei 7+/-2 Mitabeitern.

Diskussionswürdig ist die Einführung von Agile Release Trains (ART) mit einem Rhythmus von 8-10 Wochen. D.h. es werden nicht entsprechend aktuellen Empfehlungen alle 1-2 Wochen Releases durchgeführt, sondern alle 2-3 Monate. Für große Softwareprojekte im Enterprise-Umfeld gibt es kaum andere Möglichkeiten, denn mit jedem neuen Release entstehen bei Kunden mit vielen Nutzern eines Produkts hohe Aufwände für die Durchführung von Tests bis hin zur Softwareverteilung.

Gerade in der Visualisierung des Scaled Agile Framework liegt aus meiner Sicht der Mehrwert. Die verlinkten Detailseiten sind zum größten Teil bereits ausformuliert und am 13.08.2012 soll die erste vollständige Version (3.1.) veröffentlicht und ggf. auch eine Community of Practice etabliert werden. Das Ganze hat natürlich auch einen finanziellen Zweck, denn es gibt auch Trainings und eine Zertifizierung.

Die Lektüre macht für alle Agilisten Sinn, um sich einen möglichten Weg der Umsetzung von Scrum in großen Umgebungen anzusehen. Darüber hinausgehende Patterns finden sich bei mir im Scrum Pattern Repository. Grundsätzlich sind große Unternehmen ausreichend komplex, um in jedem Fall eine andere Ausprägung von Scrum über den Scrum Guide hinaus zu rechtfertigen. Frameworks wie das SAF oder meine Advanced Enterprise Patterns können lediglich ein Angebot sein, aus dem man sich für die Konzeption einer unternehmensspezifischen Methodik bedienen kann.

• Übersicht Projektmanagement-Standards
  Alter Link: www.projekt-management-beratung.com/index.php?m=wissen&s=wis_standards

• Firmen-Webseite offline
  Derzeit bewerbe ich meine Firma nicht über eine eigene Webseite und habe im Blog die entsprechenden Verweise getilgt. Alte Links enthalten teilweise:
  • www.projekt-management-beratung.com/index.php?m=philosophie&s=phi_vorgehen
  • www.projekt-management-beratung.com/index.php?m=philosophie&s=phi_code
  • www.projekt-management-beratung.com/index.php?m=philosophie&s=phi_vorgehen
  • www.projekt-management-beratung.com/index.php?m=philosophie&s=phi_pentagon
  • www.projekt-management-beratung.com/index.php?m=portfolio&s=por_methodik
  • www.projekt-management-beratung.com/index.php?m=wissen&s=wis_wissenschaft

• Artikel Schiffsmodell
  2010 habe ich die beiden Artikel Multihulls – oder das Schnellste was unter Segeln unterwegs ist sowie einen Baubericht über meine equilibrium in der Zeitschrift Schiffsmodell veröffentlicht. Welcher Link hinter der Suchanfrage “artikel_schiffsmodell” steckt, ist im Moment nicht nachvollziehbar.

Ein Servant Leader ist gekennzeichnet durch Aspekte wie Vision, Aufrichtigkeit, Integrität, Vertrauen, Service/Dienen, Vorbildwirkung, Wegbereitung, Wertschätzung und Empowerment. Gerade bei der Einführung von Scrum ist dieser Führungsstil das Mittel der Wahl.

Viel spannender sind die Kompetenzen und Eigenschaften des Creative Managers:

• Auffassungsgabe
• Unterstützung und Entwicklung der Mitarbeiter
• Eigeninitiative
• Vernetzung

Auch wenn der Artikel diesen Stil nur anreisst, finde ich den Übergang vom Servant Leader zur “Moderator” (Creative Manager) spannend. Kennt jemand diesen Führungsstil aus der Praxis?

Im Forum des Projekt Magazins gibt es zu dem Artikel eine Diskussion, die allerdings eher durch die Kollision der agilen und nicht-agilen Welt geprägt ist.

Endlich ist es soweit! openPM ist die erste freie und kostenlose Plattform für Projektmanagement-Wissen und gerade eben live gegangen. Jede Menge bekannte Blogger und Aktive der PM-Szene sind dabei und haben in der Betaphase hochwertigen Content erstellt.

Seitens Unlocking Potential finden sich dort die deutschen Übersetzungen der Scrum Pattern Bibliothek. Pro Woche übersetze ich derzeit mehrere Pattern bzw. aktualisiere sie.

Schauen Sie sich die Seite an und verbreiten Sie die Nachricht wenn ihnen die Plattform gefällt. Wenn Sie selbst mitmachen wollen, sind sie herzlich eingeladen.

Neben den Mitarbeitern, wegen denen man gerne eine Reorganisation durchführt, gibt es das Bestreben verkrustete Strukturen aufzulösen, d.h. die Organisation in Bewegung zu halten und zu optimieren. Welche weiteren Gründe haben Sie in der Praxis bei Reorganisationen gesehen?

Quelle: onefte.com

Wenig überraschend finden sich die Trends PMO, Programm-Management und Portfolio-Management. Die Rangfolge führen Change und Risk Management an, wobei die agilen Methoden leider noch weit abgeschlagen ihr Dasein fristen.

Interessant finde ich, dass zwar die Bedeutung standardisierter Vorgehensmodelle für Projektmanagement steigt, gleichzeitig aber für formale Prozesse für die Weiterentwicklung von Projektmanager-Skills und PPPM-Modellen sinkt.

Viel spannender ist eigentlicher der Reifegrad des Projektmanagement im Zusammenhang mit erfolgreichen Projekten.

Das folgende Diagramm zeigt in drei Spalten die Prozentsätze für pünktliche, budgeteinhaltende und zielerfüllende Projekte:

Grundsätzlich wird klar, dass gutes Projektmanagement den Erfolg von Projekten ganz klar steigert…wenn man Projektmanager fragt.

Bei den Erfolgsfaktoren für Projekte ergab eine Analyse der Studiendaten folgende Topliste:

1. Aktive Projektsponsoren
2. Mehr als 35% der Projektmanager sind PMP®-zertifiziert
3. Einsatz von Risikomanagement
4. Einsatz von Portfoliomanagement
5. Einsatz standardisierter PM-Methoden
6. Karrierepfad für Projekt-/Programmmanager
7. Einsatz von Change Management
8. Agiles Projektmanagement
9. PMO

Es kommt immer darauf an wonach man fragt…und die Frage nach der Qualität der Kommunikation in Projekten wurde scheinbar nicht gestellt. Diese ist einer der wichtigsten Faktoren erfolgreicher Projekte und fehlt in der Liste. Deshalb ist die Liste zwar eine interessante Auswertung der vom PMI® gestellten Fragen, allerdings keine Topliste genereller Art.

Im nationalen Bereich gibt es genügend Studien die detaillierte Informationen bieten. Für Firmen lohnt sich der Erwerb der Studie im internationalen Umfeld aus meiner Sicht. Hier einige spannende Erkenntnisse, ohne zu viel vorwegzunehmen:

• Teilnehmer
  Die Zahl der Antworten pro Land überschreitet teilweise 10.000 Antworten, wobei Belgien, Kolumbien, Irland, Malaysia, Nigeria, Peru, Spanien, Schweden, Schweiz in der 7. Auflage neu hinzugekommen sind. Die meisten Studienteilnehmer haben mindestens 5 Jahre Berufserfahrung, der Frauenanteil fiel leider sehr gering aus.

• Gehälter
  China bildet wenig überraschend das Schlusslicht, in Führung liegt die Schweiz. Dabei hat in Asien interessanterweise die Teamgröße einen großen Einfluss auf das Gehalt, in Saudi Arabien und Schweden zählt dieser Faktor dafür nicht. Ähnlich sieht es mit dem Projektbudget aus: In Saudi Arabien ist es egal, in Afrika und Südamerika dafür ein wichtiger Faktor.

• Erfahrung
  Die Hälfte aller Teilnehmer haben weder Erfahrung mit agilen Projekten bzw. Lean noch mit Wasserfallprojekten. Bei Earned Value und Prozessen wird es dann langsam besser.

• Arbeitszeit und Karriere
  Meist werden 40h Arbeitszeit erwartet und dann doch fast 50 geleistet und was ich für noch ungünstiger halte: Meist geht der Karrierepfad für Projektmanager mit einer schrittweiser höheren Linienposition einher.

Insgesamt eine spannende Studie und ich hoffe, dass das PMI noch eine kurze Zusammenfassung veröffentlicht. Diese Punkte sollen Sie lediglich auf den Geschmack bringen und sind bewusst unscharf gehalten, die genauen Daten finden Sie detailliert aufgeschlüsselt in der Studie.

Bisher gibt es die Scrum Patterns hier im Blog in englischer Sprache und ab jetzt unter openPM auch auf Deutsch. Zum Monatswechsel wird der Wiki von openPM den geschlossenen Betabetrieb verlassen und für alle verfügbar gemacht.

Die Zusammenarbeit ist deshalb so interessant, weil openPM sich zum Ziel gesetzt hat eine offene, frei zugängliche, unabhängige und nicht kommerzielle Plattform für Projektmanagement und alle, die an Projekten arbeiten zu sein. Ich glaube daran, dass es klappt.

Weniger gut geklappt hat es mit zwei anderen Projekten, die vor einiger Zeit gestartet sind:

• Auf dem Blog der GPM (Gesellschaft für Projektmanagement) bekommt man eher einfache Artikelkost und News geboten, der erhoffte Dialog bzw. Diskurs mit der GPM findet nicht statt.
• Meine Hoffnung hinsichtlich der Erweiterung von Scrum über Patterns direkt auf der Webseite von Ken Schwaber, an der auch Jeff Sutherland über den Scrum Guide beteiligt ist, hat sich ebenfalls nicht bestätigt. Bis jetzt gibt es dort nur ein einziges Pattern, welches gleichzeitig mit der Veröffentlichung des neuen Scrum Guide online ging.

Mein Ziel ist mit der Vervollständigung und Übersetzung der Scrum Pattern eine solide Grundlage zu schaffen, auf die man die Einführung und die Bewertung des Reifegrads des Einsatzes von Scrum stützen kann.