1 Jahr Enterprise Wiki – Erfahrungsbericht der T-Systems MMS

Als Betroffener einer Sharepoint-Einführung merke ich gerade, wie sehr mit ein Enterprise Wiki im aktuellen Umfeld fehlt. Es zwar schön, dass Sharepoint eine Datenbank-Anbindung hat und gut mit Office integriert ist, aber letztlich erscheint mir das Leben damit reichlich kompliziert. Deshalb hat mich der Bericht der T-Systems MMS über ein Jahr Confluence besonders gefreut. Hier die wichtigsten Punkte:

Managing by Walking Around (MBWA) – ein alter Hase berichtet

Das Blog PM Hut hat mich auf einen Artikel von Noel Hinners, einem alten NASA-Manager gebracht, der aus seinen Erfahrungen zu Managing by Wandering seit den frühen Sechzigern berichtet. Ich fand den Artikel spannend und kann ihn uneingeschränkt weiterempfehlen, wann berichtet schon ein alter Hase.

Abnahmeprotokoll (Vorlage/Template) – bis auf Nacharbeiten…

Abnahmen sind immer ein leidiges Thema. Der Kunde bekommt meist nicht genau das, was er sich vorgestellt hat und der Lieferant ist der Meinung, dass er so ziemlich alles nach Vorgaben realisiert hat. In der Praxis zeigt sich im Rahmen der Abnahme, ob die Anforderungen ausreichend präzise formuliert wurden. Ggf. gab es auch schon einen Prototypen, zu dem der Kunde Änderungswünsche äußern konnte, vielleicht war er im Rahmen eines agilen Projekts auch ständig vor Ort im Team und hat Teilabnahmen erteilt.

Wie auch immer, es muss dokumentiert werden. Dies kann man mehr oder minder aufwendig gestalten. Das hier vorgestellte Abnahmeprotokoll stellt quasi einen Mindeststandard dar, in dem jede Anforderung zu einem bestimmten Termin zur Abnahme bereitgestellt wird und von einem Verantwortlichen zu einem weiteren Datum möglicherweise mit oder ohne Kommentare abgenommen wird:

Hiring externer Projektmanager – Do’s and Don’ts

In der aktuellen Ausgabe des Projekt Magazins hat sich Michael Schiedermeier der Frage gewidmet, wie man externe Projektmanager rekrutiert. Darin weist er auf einige wichtige Punkte hin, aus meiner Erfahrung auf allen drei Seiten (Berater, Vermittler, Kunde) ergeben sich noch einige zusätzliche Anmerkungen.

Größere Unternehmen schließen heute selten direkt mit Externen Verträge ab und lagern diese Aufgabe häufig an Vermittlungsunternehmen aus. Dies hat auf der einen Seite den Vorteil der Arbeitsersparnis für das Unternehmen und ggf. günstigere Konditionen und Bedingungen durch Rahmenverträge, führt aber mangels Fachkenntnissen fast aller Vermittlungsunternehmen und dem Weg an der eigenen Personalabteilung vorbei häufig zu einem teureren und schlechteren Ergebnis, insbesondere bei komplexen Profilen wie denen von Projektmanagern.

Gerade in den Ausschreibungen findet man, wie von Herrn Schiedermeier gleich zu Anfang richtig ausgeführt, meist den Wunsch nach Allroundkünstlern, die neben tiefen Fachkenntnissen auch perfekte Projektmanager sein sollen. Diese Rolle des „technischen Seniorprojektmanagers“ ist ein klassischer Fehltritt in den üblicherweise geposteten Positionsbeschreibungen.

Wie macht man es nun richtig?

Projektsponsoren – Wie finde ich den Richtigen?

Gestern hat Ken Hanley im Project Smart-Blog ein langes Posting mit dem Titel Avoiding the accidential project sponsor veröffentlicht. Er beleuchtet das Problem des Projektsponsorings von verschiedenen Seiten, vor allem das Problem Manager als Sponsoren zu wählen, die durch den Projekterfolg/-misserfolg nicht nachhaltig betroffen sind. Das Posting ist mehr als lesenswert, zur Motivation hier einige Punkte daraus, die mir wichtig sind:

1. Ein geeigneter Projektsponsor kann die Fragen danach beantworten, wann das Projekt beendet und ob es ein Erfolg ist.
2. Mehr als ein Sponsor führt zu Problemen.
3. Die Pflichten eines Sponsors enden nicht mit dem Kickoff-Meeting.
4. Auch Sponsoren sollten geschult werden, am Besten mit Kollegen, die auf der gleichen Ebene sind.
5. Wenn der Sponsor wiederholt zu beschäftigt ist, um an den entscheidenen Meetings des Projekts teilzunehmen, ist er der falsche Sponsor.

Viel Spaß beim Lesen!

Aktualisierte und englische Templates Teil 3 (Template/Vorlage)

Nach einigen Anfragen zu englischsprachigen Templates habe ich heute den verbleibenden Teil der Templatesammlung auf pm-templates.de überarbeitet. Dabei sind auch gleich einige kleine Fehler und Ungereimtheiten in den deutschen Templates beseitigt worden. In der dritten Runde wurden geändert bzw. übersetzt:

21 Punkte-Checkliste für den guten Projektmanager

MacPM hat auf Project Smart eine gute Checkliste für Projektmanager gefunden. Alle dort aufgeführten Punkte sind mit Kurzartikeln hinterlegt und sollten definitiv in Projekten beachtet werden.

Meine Favoriten sind:

Die Steinsuppe – oder wie man Stakeholder „onboarded“

Sigrid Hauer hat wieder eine ihrer wunderbaren „Geschichten“ gepostet. Da das Thema Stakeholder in kürzester Zeit an einen Tisch bringen diese Woche bei mir dominierte, hier dazu die Geschichte über die Steinsuppe.

Im Grunde genommen verwendet der Soldat in der Geschichte eine Zwiebeltechnik, in dem er zunächst seine Suppe mit einem Stein beginnt und die Dorfbewohner nacheinander dazu bringt jeweils ein kleines Stück beizutragen, bis am Ende eine leckere Suppe entsteht.

Wie sollten Sie nun als Projektmanager vorgehen?

Ist das ein Stakeholder? Die Checkliste.

Lynda Bourne hat im PMI® Blog Voices on Project Management vor zwei Tagen eine praktische Checkliste gepostet. Dabei hat sie die Frage, wer nun Stakeholder eines Projekts ist recht praktisch beantwortet über den Anteil, den eine Person am Projekt haben kann:

• Interesse: Entscheidungen im Verlauf des Projekts oder hinsichtlich seiner Ergebnisse betreffen die Person.
• Rechte: Die Person hat das Recht in einer gewissen Weise behandelt zu werden bzw. ein Recht dieser Person muss geschützt werden im Rahmen des Projekts.
• Eigentum: Die Person hat ein Anrecht auf Assets oder Besitztümer im Zusammenhang mit dem Projekt.
• Wissen: Die Person verfügt über Wissen, dass für das Projekt benötigt wird.
• Einfluss: Die Person wird durch die Arbeit im Projekt oder dessen Ergebnisse beeinflusst, oder kann diese umgekehrt beeinflussen.
• Beitrag: Die Person trägt zum Projekt bei über Assets, Ressourcen, Budget oder Fürsprache bei.

Wie komme ich zu meinen 60 PDUs?

Gerade ist die Frage, wie man nun an die 60 PDUs in drei Jahren kommt um den PMP® zu behalten an Cornelius Fichtner gestellt worden. Randbedingung des Anfragenden ist, dass er relativ wenig des PMBOK^® Guide derzeit in der Praxis umsetzt. Hier also ein Kochrezept für die 60 PDUs in drei Jahren (vgl. auch CCR-Seite des PMI):

Wie sollten Sie sich als professioneller Projektmanager verhalten?

Gestern hat Glen Alleman in seinem Blog eine konkrete Liste von Punkten darüber, wie man sich als Projektmanager verhalten sollte, veröffentlicht. Definitiv lesenswert!

• Habe alle Fakten verfügbar!
  • Keine Sucherei in Notizen
  • Nichts erfinden
  • Nicht Leute davon überzeugen, dass die eigene Idee besser ist wenn es keine praktischen Erfahrungen und Beweise dazu gibt
  • Tiefes Verständnis von Kontext und Domäne aller Diskussionspunkte bevor Alternativen vorgeschlagen werden

Aktualisierte und englische Templates Teil 1 (Template/Vorlage)

Nach einigen Anfragen zu englischsprachigen Templates habe ich heute begonnen die Templatesammlung auf pm-templates.de zu überarbeiten. Dabei sind auch gleich einige kleine Fehler und Ungereimtheiten in den deutschen Templates beseitigt worden. In der ersten Runde wurden geändert bzw. übersetzt:

Projekttagebuch (Template/Vorlage) – Jederzeit Rechenschaft ablegen können…

So trivial die Vorlage auch ist, umso wichtiger ist ihr Einsatz. Als Projektmanager kommen Sie immer wieder in die Situation, schnell darlegen zu müssen warum etwas so passiert ist, wie es denn passiert ist. Besonders unangenehm sind Managementeskalationen, auf die man erst mit umfangreichen Recherchen nach dem warum und wer reagieren muss.

Deshalb macht es Sinn, die wichtigsten Schritte, Entscheidungen und Ereignisse eines Projekts in einem Projekttagebuch festzuhalten:

Lessons Learned – deutsch-französische Projektteams

In der aktuellen projektMANAGEMENT aktuell der GPM bin ich auf eine gute Zusammenstellung von lessons learned im Zusammenhang mit deutsch-französischen Projektteams gestoßen. Frau Dr. Danielle Dahan-Feucht gibt zusammengefasst folgende Empfehlungen im Interview:

1. Kritik muss in Frankreich indirekt und höflich an der Sache geäußert werden, denn sonst wird sie schnell als Kritik an der Person verstanden und führt damit zu Schwierigkeiten. Eine typische Variante ist, dass man dem Kritisierten darlegt, dass die Umstände vielleicht nicht so waren, dass er seine Aufgabe hätte ausführen können.
   

Wie priorisiere ich Risiken?

In den vergangenen Tagen hatte ich bereits eine Vorlage für ein Risikoregister und ein Rezept zur Klassifizierung von Risiken und Chancen gepostet. Heute nun zum Abschluss die Frage: wie priorisiere ich denn nun die vorhandenen Risiken und Chancen?

Dazu noch einmal die Priorisierungsmatrix aus dem Risikoregister: