Freitag, 29. Mai 2009

Project Server – Arbeiten mit Teamressourcen

Aktuell habe ich den Fall, dass Projektleiter ihren Vorgängen Ressourcen mit bestimmten Skills zuordnen wollen, die eigentliche echte Ressource dahinter aber nicht bestimmen dürfen. Nur der Verantwortliche für die Ressourcen (bspw. ein Teamleiter) wählt den entsprechenden Mitarbeiter aus.

Die Gelegenheit für das Feature “Teamressourcen” in Project Server 2007.

Folgender Prozess stellt sich dar:

image

Anbei mein Lernprozess zum Umgang mit Teamressourcen:

1. In den Enterprise Fields habe ich ein Feld “Teams” und eine entsprechende Nachschlagetabelle mit allen Teambezeichnungen. Jeder echten Ressource ist ein Team zugeordnet. Erwartung: In Project Professional kann ich nun Teams aus dem Enterprise Pool auswählen und zuordnen. Realität: nein, geht nicht, es fehlt ja eine entsprechende Ressource.

2. Also für jedes Team eine generische Teamressource anlegen. Die kann vom Projektleiter in das Projekt geholt werden und auch Vorgängen zugeordnet werden. Der Teamleiter erhält noch das Häkchen “Teamzuordnungspool”, welches ihn als Teamleiter definiert:

 image

Es gibt also in unserem Beispiel das Team “Network Management”. Dafür gibt es eine generische Teamressource “Team Network Management” und einen Teamleiter “Fred Feuer”. Ein Projektleiter holt sich nun über “Team aus Enterprise-Pool zusammenstellen” die Ressource “Team Network Management” in Projekt und weist ihr munter Vorgänge zu.

image

Mit dem Ziel, dass Fred Feuer eine Benachrichtigung bekommt und die Vorgänge an die Teammitglieder delegieren kann.

Realität: dies funktioniert nicht, wenn die Teamressource eine generische Ressource ist. Damit Fred nämlich die Vorgänge delegieren kann, muss er Zuordnungsbesitzer der Teamressource “Team Network Management” sein. Diese Eigenschaft gibt es bei generischen Ressourcen nicht.

3. Also hab ich aus die Ressource “Team Network Management” zu einer echten Ressource gemacht und den Teamleiter als Arbeitszeittabellen-Manager und Zuordnungsbesitzer festgelegt.

image
Erwartung: nun kann der Teamleiter in PWA unter “Meine Aufgaben > Arbeit neu zuordnen” die Vorgänge an die Teammitglieder vergeben.
Realität: Pustekuchen. Im Dropdown unter “Vorgangsneuzuordnungen” fehlen die Teammitglieder. Hier ist auch die Microsoft Dokumentation sehr missverständlich, die dauernd von “Team” redet. Gemeint ist das Projektteam, also alle Ressourcen die im Projekt importiert sind und nicht das Team, welches im Ressourcenpool definiert ist.

4. Der Projektleiter muss also ALLE Teammitglieder (auch Teamleiter) UND die Teamressource in sein Projekt holen, aber nur der Teamressource die Vorgänge zuordnen.

image

Das führt natürlich irgendwann dazu, dass in PWA die Sichten mit den Projektzuordnungen ihre Aussagekraft verlieren, da alle Ressourcen bald allen Projekten zugeordnet sind, damit sie überhaupt die Möglichkeit haben vom Teamleiter Vorgängen zugeordnet werden zu können. :( very bad, Microsoft

 

image5. Der Teamleiter erhält nun sogar eine Email über die Zuordnungen vom Projektleiter, die Teamressource gehört ja zu seinem Team (trinkt lediglich keinen Kaffee weg und macht keine Arbeit).

 

image 6. In PWA kann er nun den Vorgang an ein Teammitglied delegieren. In meiner VM hat das Teammitglied leider keine Benachrichtigungsemail bekommen. Ich weiß aber aktuell nicht, ob es generell so ist, oder ob bei mir nur etwas falsch konfiguriert ist. Die Erwartung hätt ich schon.

 image7. Anschließend kann der Projektleiter die Neuzuordnung in Project Prof. genehmigen oder ablehnen. Über eine Ablehnung bekommt der Teamleiter aber keine Benachrichtigungsemail, was sehr schade ist.

 

8. Der Teamleiter ordnet bei einer Ablehnung einen anderen Mitarbeiter zu (der bei mir wiederum keine Benachrichtigungsemail erhalten hat)

image 

Fazit:

Schlecht ist, dass ich alle Ressourcen eines Team in das Projekt importieren muss. Das führt zu einem Wildwuchs an Projektzuordnungen. Hier sollte ProjectServer von Teammitgliedschaft auf Ressourcen schließen können.

Unzureichend ist auch die nicht konsequent durchgezogene Benachrichtigung bei Neuzuordnungen. Ich kann als Projektleiter einen Kommentar eingeben, wenn ich eine Ressourcenänderung ablehne, der Teamleiter erhält aber keine Email und reagiert u.U. überhaupt nicht auf die Ablehnung. Der Projektleiter muss also hinterher telefonieren.

Ansonsten funktioniert so aber die Delegierung von Vorgängen durch einen Teamleiter sehr gut.

Mittwoch, 27. Mai 2009

2. SharePoint UserGroup Treffen in Hamburg

Gestern fand das 2. Treffen der Hamburger SharePoint UserGroup bei Computacenter statt.

Zentrales Thema war diesmal die Umsetzung von Barrierefreiheit mit SharePoint CMS. Fazit: Barrierefreie Webseiten mit MOSS sind möglich, aber es steckt ein gewisser Aufwand dahinter. Auch sollte man sich vor einem MOSS CMS Projekt überlegen, ob Barrierefreiheit eine Anforderung ist, das reduziert den Aufwand erheblich. Bestehende MOSS Publishing Sites (möglichst noch gespickt mit Webparts) sind nur mit hohem Aufwand barriefrei zu machen.

Andreas Witt von HanseVision zeigte in seinem Vortrag detailliert die Probleme, Strategien und nützliche Tools auf.

Slide Deck zum Download: MOSS WCMS und Barrierefreiheit.pptx

Fotos folgen noch.

Die nächsten Treffen finden am 7.Juli und am 15. September statt.

Thema am 7.Juli wird sein: Office und Outlook als SharePoint Frontend

Weitere Themenvorschläge für die nächsten UserGroup Treffen:

  • Workflows mit SharePoint Designer und Nintex Workflow
  • Projektmarketing - erfolgreich SharePoint im Unternehmen einführen
  • Project Server 2007 und MOSS