In diesem Blog-Artikel soll exemplarisch und vereinfacht aufgezeigt werden, wie ein an Prince2® angelehnter Projektraum mit SharePoint2010 Bordmitteln ausgestaltet sein kann, um Prince2® basierte Projekte als Projektinformationsplattform zu unterstützen. Prince2® steht für “Projects in Controlled Environments” und ist eine der am weitesten verbreiteten Projektmanagement-Methoden.

Wichtig ist an dieser Stelle der Hinweis, dass dieser Projektraum nicht streng nach Prince2® aufgebaut ist und nicht den Standards der OGC entstammt, sondern dieses Beispiel lediglich an Prince2® angelehnt ist.

Die verwendeten deutschen Prince2®-Begriffe sind der offiziellen Prince2®-Übersetzungsliste entnommen, der englische Originalbegriff ist an geeigneter Stelle ebenfalls in Klammern genannt.

Kernelemente des Projektraums

  • Phasen (Stages) – Phasen sind die oberste Ebene der konkreten Projektplanung und können als Projektaufgabenliste mit einer Gantt-View abgebildet werden. Diese Phasen-Liste dient einmal dazu das Projekt auf der obersten Ebene zu strukturieren und die Struktur sichtbar zu machen. Im weiteren Verlauf kann eine Strukturierung der Produkte des Projekts in der SharePoint-Oberfläche, sowie die Zuordnung zu Phasen erreicht werden. Zur weiteren Klassifizierung einer Phase können bei Bedarf weitere Spalten erzeugt werden, zum Beispiel um eine Phase als „Management Phase“ oder als „Technische Phase“ ausweisen zu können.

image1

  • Produkte (Products) – Die Produkte sind die Kernelemente der ergebnisorientierten Planung in Prince2®. In diesem Beispiel werden Produkte in einer SharePoint-Liste abgelegt und verwaltet. Die Liste ist als Custom-List erzeugt und wurde um die Spalten „Lieferdatum“, „%abgeschlossen“, „Verantwortlich“, „Beschreibung“ und „Stage“ bzw. „Phase“ erweitert. Die Stage dient an dieser Stelle dazu, die Liste der Produkte zu strukturieren. Zusätzlich wird eine Spalte erzeugt, in der der volle Produktename bestehend aus Phasenname und Produkt-Titel automatisch generiert wird, diese wird hier einfach „Produkt (voll)“ genannt. Diese Spalte berechnet sich aus dem Stagenamen und dem Produktnamen und wird automatisch per Workflow mit Inhalten gefüllt. Dieser Wert wird in Arbeitspaketen, Dokumenten und in der Liste offener Punkte als Referenz verwendet. Auf diese Weise wird die in Prince2® geforderte Ergebnisorientierung erzeugt und kann durchgängig als Strukturierungselement genutzt werden.

image2

  • Arbeitspakete (Workpackages) – Arbeitspakete sind die notwendigen Tätigkeiten und Informationen, die zur Erstellung eines Produkts notwendig sind. Hier sind in der praktischen Anwendung betriebliche Prozesse zu beachten, zur Bearbeitung der konkreten Arbeitspakete gibt es meist bereits spezialisierte Tools und Workflows in der jeweiligen Fachdomäne. Beispiele sind hier Change Management Systeme und Configuration-Item Datenbanken in ITIL-basierten Umgebungen. Arbeitspaketlisten enthalten also nur gerade so viel Information, wie es zur Verwaltung des Projektes notwendig ist. Die Abarbeitung des Arbeitspakets wird jedoch nicht im Projektraum gesteuert. So benötigt die Installation eines Datenbank-Servers eine Reihe von Einzelschritten. Aus Projektsicht braucht es jedoch nur einen Namen, die Zuordnung zu einem Produkt, die Spezifikation des erwarteten Ergebnisses, das Fertigstellungsdatum und einen Verantwortlichen. Alle weiteren technischen Detailschritte können in den etablierten IT-Servicemanagement-Tools verwaltet werden. Es erfolgt also kein Bruch zwischen Projekt und Standardprozess. Die Standard-Aufgabenliste wird in diesem Beispiel um die Spalte Produkt erweitert, die das Feld „Produkt (voll)“ referenziert.
  • Risikoregister (Risk Register) – Das Risikoregister enthält die Risiken, die während des Projektes eintreten können. Umgesetzt werden kann diese mit einer Liste, die die Spalten, Titel, Risikobeschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Stage, Beschreibung der Auswirkung, Maßnahmen zur Vermeidung, Maßnahmen bei Eintreten und einem für dieses Risiko Verantwortlichen enthält. Die Spalte Stage enthält die Phase bzw. Stage in der das Risiko wahrscheinlich auftreten wird und referenziert den Phasennamen der Phasenliste. Ein Risiko kann hier auch mehreren Phasen zugeordnet werden. Die Darstellung kann jetzt über SharePoint-Ansichten erfolgen, in dem das Risikoregister mit den Filter-, Sortierungs- und Gruppierungsmöglichkeiten zum Beispiel nach Eintrittswahrscheinlichkeit oder nach Auswirkung gruppiert wird.
  • Register offener Punkte (Issue Register) – Das Issue Register sammelt sämtliche Probleme, offenen Punkte und ungeklärte Fragen, die während des Projekts auftreten und formal erfasst und behandelt werden sollen, die also eine Relevanz auf der Projektsteuerungsebene haben. Hier wird die Problemverfolgungsliste des SharePoint verwendet und um die Spalte „Produkt“ erweitert, die die Spalte „Produkt (voll)“ der Produktliste referenziert. Auch hier dient dies wieder der durchgängigen Ergebnisorientierung. Im konkreten Anwendungsfall sind die verwendeten Spalten, wie bei allen Listen in diesem Beispiel, natürlich an die jeweiligen Anforderungen anzupassen. Auch hier gilt ähnliches, wie für Arbeitspakete, es wird kein paralleles Tool zu etablierten Incident-Management-Systemen geschaffen, sondern es werden nur die Informationen gesammelt und nachverfolgt, die auf Projektsteuerungsebene notwendig sind. In der Regel werden technische Detailprobleme, die während der Bearbeitung der Arbeitspakete auftreten auch hier in der Regel nicht als Issue erfasst, solange diese nicht auf der Projektsteuerungsebene behandelt werden müssen.

image3

  • Freigegebene Dokumente – Zur Verwaltung der Projektdokumente kommt eine SharePoint-Dokumentenbibliothek zum Einsatz. Auch hier wird die Ergebnisorientierung durch eine Referenz auf das Produkt erzeugt. Dokumente sind damit eindeutig einem Prince2®-Produkt zugeordnet und können danach gruppiert werden. Hier wird dem einen oder anderen ein Widerspruch zur Sichtweise von SharePoint auf Dokumente auffallen. Die feste Zuordnung eines Dokuments zu einem Produkt erinnert stark an Ordnerhierarchien, die in SharePoint2010 aufgebrochen werden. Ob im konkreten Fall ein Dokument an ein oder an mehrere Produkte gebunden sein soll, bleibt der Anwendung der Methode in der jeweiligen Organisation überlassen. Oft wird ein Dokument jedoch nur einem Produkt zugeordnet, da jedes Produkt eindeutige voneinander abgrenzbare Ergebnisse haben sollte.

image4

Weitere Listen, die zum Einsatz kommen können, sind:

  • Qualitätsregister (Quality Register)
  • Projekttagebuch (Daily Log)
  • Erfahrungsprotokoll (Lessons Log)

Diese sollen aber an dieser Stelle nicht weiter dargestellt werden, da sie den bereits genannten Listen sehr ähnlich sind.

Als letztes Element soll an dieser Stelle der Kalender genannt werden. Im Kalender werden Projekttermine verwaltet und mit Hilfe von Kalenderüberlagerungen können Projektmeetings, Termine und Abgabefristen dargestellt werden. Durch Verwendung von Ansichten und Kalenderüberlagerungen müssen Termine, die bereits in verschiedenen Listen vorhandenen sind (z.B. Abgabetermine von Ergebnissen) nicht von Hand in den Kalender eingepflegt werden. Zusätzlich lässt sich der Projektkalender in Outlook integrieren und mit dem persönlichen Kalender überlagert werden. Termine müssen also nicht mehrfach gepflegt werden, um im Bedarfsfall eine zentrale Übersicht zu haben.

Ein wesentlicher Vorteil, den SharePoint 2010 an dieser Stelle bietet, ist die Zielgruppen-orientierte Aufarbeitung von Daten aus diesen Listen in speziellen Views und Webparts.

Zum Beispiel bietet sich die Startseite des Projektraums an, um Anwendern personalisierte Informationen, wie ihre Produkte, ihre Arbeitspakete und die Dokumente an denen gearbeitet wurde, anzuzeigen. In weiteren Ausbaustufen sind Dashboards und weitere Übersichten denkbar.

image

Diese Basis ergibt einen an Prince2® angelehnten Rahmen, der erweitert und an die individuellen Anforderungen angepasst werden kann. Das Beispiel ist bewusst einfach gehalten und soll eine Basis aufzeigen, auf der weitergearbeitet werden kann. Prince2® ist eine Methode, die an das jeweilige Projekt und die jeweilige Organisation angepasst werden sollte. SharePoint 2010 ist eine technische Plattform, die ebenfalls darauf ausgelegt ist an Anforderungen und Bedürfnisse angepasst zu werden.

Ein SharePoint 2010 basierter Projektraum bietet also die Möglichkeit, dem „Prince2®-Tailoring“ zu folgen und bietet damit eine ideale Plattform zur Verwaltung Prince2®-basierter Projekte.

1 Comments

  1. Pingback: Beispiel eines an Prince2® angelehnten Projektraums in SharePoint 2010 - SharePoint Blogs in German - Bamboo Nation

Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Time limit is exhausted. Please reload the CAPTCHA.