P3O etabliert eine Unterstützungs- uns Supportstruktur für das Management jeglicher Änderungen eines oder mehrerer Unternehmen. Warum? Für das Management ist es wichtig im richtigen Moment die richtigen Entscheidungen zu treffen. Basis dieser Entscheidungen sollten immer die vorliegenden Informationen sein. Damit nun die richttigen Informationen zur Verfügung stehen sorgt eben diese unterstützende Struktur verschiedener Offices. Dies als ganzes bezeichnet man P3O.

Es werden Modelle, Funktionen, Techniken und Rollen beschrieben, mit denen die Portfolio-Entwicklung sowie Programme und Projekte in ihrer Durchführung unterstützt werden können.

Jedes Projekt, jedes Programm ist bezüglich des Erfolgs oft von einer guten administrativen Unterstützung und Infomrations-sichernden Beratung abhängig. Dies zu zentralisieren und standardisierte Methoden (mit vielen praktischen Beispielen) an die Hand zu geben ist die Aufgabe des neues Frameworks P3O. 

Es fügt sich nahtlos in PRINCE2 ein, indem es z.B. Rollen für die Projektsicherung und Projektunterstützung bereitstellt.

Weitere Informationen finden Sie hier…

Ich wünsche allen ein frohes neues Jahr!  … und viel Spaß bei den weiteren interessanten Beiträgen rund um das Projektmanagement mit PRINCE2!

Das Team vom PRINCE2-Blog und der SERVIEW wünscht allen Lesern ein frohes Weinhnachtsfest 2010 und einen guten Rutsch nach 2011. Das neue Jahr wird uns wieder viele neue Projekte bringen und wir stehen Ihnen dazu gerne in jeder Hinsicht als Hilfe zu Verfügung. Freuen Sie sich in 2011 auf neue Themen wie Risikomanagement mit M_o_R, Portfolio-, Programm-, und Project Offices mit P3O, Programm Managememt mit MSP, Portfolio Management mit MoP und das Thema Change Management. Nähere Informationen dazu finden Sie schon heute auf www.serview.de.

Das Thema Risikomanagement bekommt immer größere Bedeutung.

Schaut man in verschiedene Projekte hinein, wird festgestellt, dass gutes Projektmanagement auch immer häufiger ein gereiftes Wissen zum Thema Risikomanagement voraussetzt. Im PRINCE2 Sinne ist ein charakteristisches Merkmal für Projekte, die mit ihnen einhergehendes Unsicherheit. Und “eine Unsicherheit in Bezug auf das Ergebnis” ist die Definition eines Risikos.

Gutes Risikomanagement kann die Unsicherheit nicht völlig beseitigen - sie aber durchaus kalkulierbar machen. Böse Überraschungen in Projekten werden seltener und damit erhöht sich die Zahl der Projekte, die ihre Ziele erreichen.

Im Rahmen der Corporate Goverance gehört Risikomanagement als wichtiger Baustein zur Internal Control. Viele Bereiche benötigen Risikomanagement. Angefangen vom Portfolio Management, welches die richtigen Entscheidungen treffen möchte, über das Programm- hin zum Projektmanagement - ganz zu schweigen von den operativen Bereichen. Auch in ITIL findet man die Notwendigkeit Risikomanagement anzuwenden: z.B. im Availability Management oder im Change Management.  

Abhilfe schafft hier - und die persönlilchen Meinung sei mir gestattet - auf eine selten konkrete Weise das Buch Management of Risk der OGC. Konkrete Techniken und Vorgehensweisen, wie z.B. Analysemethoden werden verständlich dargestellt und in den Gesamtzusammenhang gesetzt. Danach bleibt Risikomanagement kein Buch mit sieben Siegeln.

Wie bereits in einem vorherigen Eintrag beschrieben gibt es hier sehr gute Schulungen, die den Umgang mit Risiken - von der Identifizierung bis zur Implementierung von entsprechenden Maßnahmen - umfassen. Gutes Risikomanagement hilft in sehr vielen Bereichen. Bestücken Sie Ihren persönlichen “Handwerkskoffer” und erleichtern Sie so Ihren Arbeits- oder Projektalltag. Mehr Information erfahren Sie unter www.managementofrisk.de

Auch wenn die “Weltliteratur des Projektmanagements” es nun wirklich in allen Farben und Formen bereits beschrieben hat und es auch unter neuen Projektmanagern bekannt ist, findet der ganz normale Wahnsinn des Projektmanagements immer wieder statt. Und so langsam frage ich micht wirklich warum?

Es sollte sich so langsam durchsetzen, dass Literatur wie PRINCE2 nicht einfach zum Spass geschrieben wurde. Nein - es könnte gar eine gute Anregung sein, nach dieser Methodik zu verfahren und eine ernstzunehmende Alternative zum bisherigen Projektvorgehen darstellen,..

ABER NEIN! Noch immer scheitern Projekte an handwerklichen Fehlern des Projektmanagements. Und damit will ich nicht sagen, dass Projekt nicht scheitern dürfen. Natürlich scheitern Projekte! Alleine schon weil in der Entwicklung der Produkte ungeahnte Schwierigkeiten auftauchen können oder sich die “politsche Windrichtung” im Unternehmen ändert. Aber Projekte dürfen und müssen nicht scheitern wegen schlechtem “Projekthandwerk”. Handwerklich schlechtes Vorgehen - also schlechtes Projektmanagement - muss es heute nicht mehr geben.  Projekte, die aufgrund handwerklicher Fehler scheitern, scheitern an Unwissen oder Besserwissen - was in diesem Fall das gleiche bedeutet. Und das muss nicht sein.

Sie fragen sich, wovon ich rede?  Ganz einfach: Hier ein paar Erlebnisse aus meinem Projektalltag…

1. In einem Pflichtenheft, welches ich vor kurzem in einem großen Projekt las - es ging um die Migration von Notes auf Exchange - fand sich folgende Formulierung unter dem Stichpunkt Qualitätskriterien: “Die Anwendung soll wie gewohnt zur Verfügung stehen!”

2. Nach einer Eskalation aufgrund drohender Toleranzüberschreitung antwortete der Vorsitzende des Lenkungsausschusses dem Projektmanager mit dem Statement: “Jetzt zeigen Sie uns erst einmal auf, was sie persönlich dafür unternommen haben, dass das, was jetzt passiert ist, nicht passiert!”

3. In einem großen Projekt zwischen einem IT-Dienstleister und einer Bank wurden einfach keine Abnahmekriteren für das Endprodukt vereinbart. Der IT-Dienstleister versucht nun - inzwischen 2 Jahre über den Liefertermin und einem Business Case der sich schon lange nicht mehr rechnet - krampfhaft die Erwartungen - wohlgemerkt Erwartungen! -des Kunden zu erfüllen!

4. Das es Projekte ohne Business Case gibt, mag der ein oder andere schon erlebt haben. Aber das geht deutlich skuriler: Vor kurzem hatte ich das Glück beratend ein Projekt zu erleben, wo ein Business Case existierte, dieser aber vor dem Projektmanager geheim gehalten wurde!!!  Sehr beachtlich, oder?

 Und jetzt frage ich Sie: Muss das so sein? Nein - nicht wirklich!

Das einzige, was mich hoffen lässt, ist, dass PRINCE2 auf alle diese Dinge eine Antwort kennt!

Sollten Sie ebenfalls bereits Bekanntschaft mit dem ganz normalen Wahnsinn gemacht haben, freue ich mich über Ihre Geschichten….

 Bis dahin…

PS: Abhilfe gibt es übrigens unter www.prince2.de

Diese Frage stellt sich so mancher Projektmanager wie auch Entscheider.

Aber warum eigentlich? PRINCE2 macht uns das relativ schnell klar: Die Erfahrung hat gezeigt, dass ein Projekt nur von Erfolgt gekrönt ist, wenn das Projekt eine fortlaufende geschäftliche Rechtfertigung besitzt. Dieses Grundprinzip aus PRINCE2 wird durch ein zentrales Dokument geprägt: Der Business Case.

Der Business Case dokumentiert die geschäftliche Rechtfertigung eines Projekts über die gesamte Projektlaufzeit hinweg. Vielfach wird auch davon gesprochen einen Business Case zu rechnen. Dies ist nicht falsch, da ein Business Case bei wirtschaftlich gerechtfertigten Projekten auch immer eine Investitionsrechnung enthält. Dies ist aber nur ein Teil eines Business Case für ein Projekt.

Ein Business Case enthält laut PRINCE2 die Beschreibung des zu erwartenden Nutzens, erwartete negative Nebeneffekte des Projekts, Hauptrisiken im Zusammenhang mit der Erreichung des Ziels und des Nutzens, dazu auch Angaben zu Zeiten und zu Kosten für das Projekt.

Ein Business Case soll während eines Projektes immer zeigen, dass sich ein Projekt lohnt. Deshalb muss dieser während des Projekts immer im Auge behalten werden, wenn notwendig aktualisiert werden und dann als Basis zur weiteren Ausführung als Entscheidungsgrundlagen herangezogen werden.

Wollen Sie mehr zu PRINCE2 erfahren? Kommen Sie einfach auf www.PRINCE2.de

Sie kennen das Thema Risikomanagement aus PRINCE2? Sie interessieren sich für den dahinterstehenden gesamtheitlichen Ansatz? Dann ist das Framework M_o_R genau das Richtige für Sie.

Unter dem Mantel der OGC wird seit 2002 ein allgemeines Risikomanagementframework bereitgestellt. Dies wird unter dem Namen M_o_R (Management of Risk) publiziert, basiert auf Best Practice und ist sowohl eigenständig als auch in Kombination mit weiteren OGC-Frameworks (z.B. ITIL, PRINCE2, MSP) einsetzbar. Gerade in ITIL, PRINCE2 und MSP wird im Rahmen des Risikomanagements das Framework M_o_R als Grundlage eingesetzt.

SERVIEW bietet seit Mai das gesamte Framework im Rahmen der Beratung und im Traingsumfeld an. Die Ausbildung zu M_o_R ist ähnlich zu der in PRINCE2 aufgebaut: Eine M_o_R Foundation und ein M_o_R Practitioner. Die ersten Kurse wurden schon erfolgreich durchgeführt.

Gehören Sie mit zu den ersten Teilnehmern in Deutschland die sich in M_o_R ausbilden lassen. Weitere Informationen zu M_o_R erhalten Sie unter http://www.serview.de/projekt-management/prince2-schulung/m_o_r-schulungen

Dieses Grundprinzip bezieht sich abschließend auf die Anpassung der Projektmanagementmethode auf die jeweiligen Umgebungen eines Projekts. Das Vorhandensein einer Methode wird vielfach begrüßt aber sobald es auf besondere Formen von Projekten angewandt werden soll häufig als starres oder bürokratisches Gerüst empfunden. PRINCE2 basiert auf praktischen Erfahrungen und hat für die unterschiedlichsten Projekte (Größe oder Art) konkrete Empfehlungen zur Anpassung parat. Damit kann die Methode flexibel und vor allem pragmatisch auf unterschiedliche Projekte angepasst werden.

Sie suchen nähere Informationen zu PRINCE2? Kommen Sie einfach auf www.PRINCE2.de

Gerade dieses Prinzip ist der Kern der Projektmanagementmethode PRINCE2. Allgemein geht der Planungsansatz in den meisten Methoden aktivitätenbasiert voran. PRINCE2 beginnt in der Planung noch einen Schritt zuvor, nämlich in der Identifizierung des zu erstellenden Produkts. Produktorientierung bedeutet dabei, dass alle in einem Projekt zu erstellenden Aspekte zunächst in Form von Produkten beschrieben werden (soweit ausreichend, dass die Entwicklung in die korrekte Richtung weist). Erst danach widmet man sich den zur Entwicklung notwendigen Aktivitäten. So wird sichergestellt, dass man sich zunächst genauer mit dem Umfang und den Merkmalen der entstehenden Elemente befasst.

Sie suchen nähere Informationen zu PRINCE2? Kommen Sie einfach auf www.PRINCE2.de.

Wodurch wird in Projekten viel Zeit vergeudet? Häufig durch unzählige Statusmeetings und unnötige Eskalationen. PRINCE2 hat dazu den Aspekt der Toleranzen definiert. Toleranzen definieren Handlungsspielräume. Diese werden über die verschiedenen Aspekte und Ebene des Projektes definiert. Eine Eskalation ist nur dann nötig wenn ein zuvor definierter Handlungsspielraum nicht ausreichend ist.  Somit wird die Häufigkeit unnötiger Klärungen und Meetings deutlich reduziert und die Konzentration auf das Erreichen des Projektziels gerichtet.

Sie suchen nähere Informationen zu PRINCE2? Kommen Sie einfach auf www.PRINCE2.de.