Projektmanagementplan

Projektname

Klassifizierung	Wählen Sie ein Element aus.
Status	Wählen Sie ein Element aus.
Programmname
Projektnummer
Projektleiter	Projektleiter
Version	0.1
Datum	Klicken Sie hier, um ein Datum einzugeben.
Auftraggeber	Auftraggeber
Autor/Autoren
Verteiler

Änderungsverzeichnis

Version	Datum	Änderung	Autor
0.1

Tabelle 1:	Änderungskontrolle

Beschreibung

Der Projektmanagementplan beinhaltet die Gesamtplanung des Projekts und die wesentlichen Regelungen zu Methoden, Techniken, Rollen und Hilfsmitteln, die projektspezifisch festgelegt werden. Der Projektmanagementplan dient als einheitliche Handlungsgrundlage für alle Projektbeteiligten. Er wird im Projektverlauf nach dem Prinzip der rollenden Planung und Steuerung kontinuierlich konkretisiert und nachgeführt. Bei Phasenabschluss wird der Projektmanagementplan zur Abwicklung der nächsten Phase den veränderten Bedingungen angepasst.

Projektbeschreibung

Kurze Beschreibung des Projektinhalts

Szenario mit Phasen und Meilensteinen

Mit Microsoft PowerPoint anpassbar (rechte Maustaste – Präsentation-Objekt – Open)

Abb. 1 -	Grafik Phasen und Meilensteine

Organisation

Rollenbesetzung

Rolle in der Stammorganisation	Name	Kürzel	Organisationseinheit
Leitung:
Controlling- und Vorgabestellen: Interne Revision	Paul Hauser	hap	ABC
Kompetenzzentrum für Projektmanagement:

Tabelle 2:	Stammorganisation

Rolle in der Projektorganisation	Name	Kürzel	Funktion / Vertretene Organisationseinheit
Auftraggeber	Kurt Mahler	mak	Leiter Direktion xyz
Projektausschuss
Projektleiter	Leon Huber	hul
ISDS-Verantwortlicher
Fachspezialist Anwendervertreter
Fachspezialist Geschäftsprozessverantwortlicher

Tabelle 3:	Projektorganisation der nächsten Phase

Organigramm

Mit Microsoft PowerPoint anpassbar (rechte Maustaste – Präsentation-Objekt – Open)

Abb. 2 -	Grafik Projektorganisation

Eskalation

Eskalationen finden im Rahmen der Projektorganisation statt.

Kann ein Problem nicht auf einer Stufe innerhalb von 5 Tagen gelöst werden, wird es an die nächste Stufe eskaliert.

Projektergebnisstruktur

Mindmap, hierarchische Darstellung

Der Projektergebnisstrukturplan ist die hierarchisch gegliederte Darstellung des Projektinhalts (Produkt-Breakdown-Structure PBS)

Mit Microsoft PowerPoint anpassbar (rechte Maustaste – Präsentation-Objekt – Open)

Abb. 3 -	Grafik Projektergebnisstrukturplan

Szenario mit Projektstrukturplan

Phasen, Module, Aufgaben, Ergebnisse, Rollen

Projektstrukturplan aus HERMES online, bzw. Hinweis auf separates Dokument

Abhängigkeiten

Abhängigkeit
Vorhaben	Auftrag/Massnahme XY
Projektrelevante Themen
Projektrelevantes Ergebnis / Entscheidung / Fakt
Termin	07.05.2021
Auswirkungen auf das Projekt
Ansprechperson	Projektleiter

Tabelle 4:	Abhängigkeiten

Prüfplan

Ergebnisse aus Projektstrukturplan übernehmen

Phase / Ergebnis	Prüfmethode	Verantwortlich	Prüfer	Termin	Status
Konzept
Phasenbericht	Review	Auftraggeber	Sutter, Huber	15.05.2020	genehmigt

Tabelle 5:	Prüfplan

Prüfmethoden gemäss Anhang Qualitätssicherung

Terminplan

Detailplanung für aktuelle bzw. nächste Projektphase
evtl. Hinweis auf externes Dokument

Meilenstein	Datum Plan	Datum ist
Projektinitialisierungsauftrag
Variantenwahl
Projektfreigabe
Phasenfreigabe Realisierung
.......
Phasenfreigabe Einführung
Betriebsaufnahme
Projektabschluss

Tabelle 6:	Meilensteine und Termine

Kostenplan

In der Regel in einem separaten Dokument, gemäss den Vorgaben der Stammorganisation

Ressourcenplan

Personalressourcen

Rolle / Person	Monat 1	Monat 2	Monat 3	Monat 4	Monat 5	Total	Bestätigung Vorgesetzter
Name
Name

Tabelle 7:	Personalressourcen

Sachmittel

Räume, IT-Infrastruktur, Spezifische Software, etc.

Beschaffungsplan

Bedarf / Bezeichnung	Menge	Wert CHF	Zeitpunkt	Beschaffungsart
Business-Analyst	20 AT	20‘000	20.1 – 30.03.2020	Freihändiges Verfahren mit mehreren Offerten
Entwickler	300 AT	280‘000	01.04.2021 – 30.06.2021	Offenes Verfahren, WTO
DB-Analyse	100 Std	18‘000	20.01. – 30.03.2021	Abruf auf Rahmenvertrag
Tools & Services	400 Std	48‘000	01.07.2020- 30.06.2020	Einladungsverfahren

Tabelle 8:	Beschaffungsplan

Kommunikationsplan

Adressat der Information	Kommunikationsverantw.	Inhalt	Ziel	Mittel / Medium	Termin
Alle Mitarbeitenden	Auftraggeber	Einführung der neuen Lösung	Alle Mitarbeitenden kennen Vorgehen, Termine und Supportorganisation	Flyer (per mail)	12.3.2020

Tabelle 9:	Kommunikationsplan

Reporting

Ergebnis	Periodizität	Verantwortlich	Empfänger	Termin
Projektstatusbericht	Monatlich	Projektleiter	Auftraggeber	Erster Arbeitstag des Monats
Phasenbericht	Ende der Phase Konzept	Projektleiter	Auftraggeber	Siehe Planung

Tabelle 10:	Reporting

Vorgaben, Methoden und Werkzeuge

Titel	Vorgaben, Methoden und Werkzeuge	Version
Projektmanagement	HERMES	HERMES 5.2
Beschaffung	BöB, VöB
Software für xyz	Tool aaa	10.2

Tabelle 11:	Vorgaben, Methoden und Werkzeuge

Abkürzungen und Glossar

Abkürzung / Fachwort	Erläuterung
HERMES	Vorgehensmethodik für Projekte und Programme HERMES 5 ist ein eCH Standard

Tabelle 12:	Abkürzungen und Glossar

Inhaltsverzeichnis

Änderungsverzeichnis	1

Beschreibung	1

1	Projektbeschreibung	2

2	Szenario mit Phasen und Meilensteinen	2

3	Organisation	2

3.1	Rollenbesetzung	2

3.2	Organigramm	3

3.3	Eskalation	3

4	Projektergebnisstruktur	4

5	Szenario mit Projektstrukturplan	4

5.1	Phasen, Module, Aufgaben, Ergebnisse, Rollen	4

5.2	Abhängigkeiten	4

6	Prüfplan	5

7	Terminplan	5

8	Kostenplan	5

9	Ressourcenplan	5

9.1	Personalressourcen	5

9.2	Sachmittel	6

10	Beschaffungsplan	6

11	Kommunikationsplan	6

12	Reporting	6

13	Vorgaben, Methoden und Werkzeuge	6

Abkürzungen und Glossar	8

Inhaltsverzeichnis	9

Abbildungsverzeichnis	10

Tabellenverzeichnis	10

Anhänge	11

Anhang A	Qualitätssicherung	11

Anhang B	Risikomanagement	12

Anhang C	Eskalationsvorgehen	14

Anhang D	Dokumentmanagement	15

Anhang D.A	Dokumentablage	15

Anhang D.B	Namenskonventionen	15

Anhang D.C	Versionen von Dokumenten	15

Anhang E	Änderungsmanagement	17

Abbildungsverzeichnis

Abb. 1 -	Grafik Phasen und Meilensteine	2

Abb. 2 -	Grafik Projektorganisation	3

Abb. 3 -	Grafik Projektergebnisstrukturplan	4

Abb. 4 -	Risikomatrix	13

Abb. 5 -	Grafik Versionsmanagement	15

Abb. 6 -	Grafik Änderungsmanagement	17

Tabellenverzeichnis

Tabelle 1:	Änderungskontrolle	1

Tabelle 2:	Stammorganisation	2

Tabelle 3:	Projektorganisation der nächsten Phase	3

Tabelle 4:	Abhängigkeiten	4

Tabelle 5:	Prüfplan	5

Tabelle 6:	Meilensteine und Termine	5

Tabelle 7:	Personalressourcen	5

Tabelle 8:	Beschaffungsplan	6

Tabelle 9:	Kommunikationsplan	6

Tabelle 10:	Reporting	6

Tabelle 11:	Vorgaben, Methoden und Werkzeuge	7

Tabelle 12:	Abkürzungen und Glossar	8

Tabelle 13:	Qualitätssicherung	11

Tabelle 14:	Bewertungsskale Eintretenswahrscheinlichkeit	12

Tabelle 15:	Bewertungsskale Auswirkungsgrad	12

Tabelle 16:	Risikomatrix	13

Anhänge

Qualitätssicherung

Das Testen wird im Testkonzept festgelegt.

Die Prüfungen werden im Kapitel Prüfplan des Projektmanagementplans festgelegt.

Die folgenden Prüfmethoden werden im Projekt eingesetzt.

Prüfmethode	Beschreibung
Schriftlicher Review (SR)	Das Ergebnis wird den Prüfern per Email zugestellt. Diese prüfen das Ergebnis unabhängig voneinander und erstellen einen Prüfbericht mit den Befunden. Die Befunde werden vom Autor korrigiert oder mit einer schriftlichen Begründung zurückgewiesen, welche dem Prüfer per Email zugestellt wird.
Mündlicher Review (MR)	In einem Review-Meeting werden die schriftlichen Befunde besprochen. Dabei werden die nötigen Anpassungen / Massnahmen beschlossen, Verantwortlichen zugewiesen und terminiert. Ein schriftlicher Review (SR) ist immer Basis für einen mündlichen Review (MR). Als Resultat eines MR entsteht ein Reviewprotokoll, das von MR-Teilnehmern unterschrieben werden muss.
Walk-Trough (WT)	Ein Walk-Through ist eine weniger formale Prüfung als ein Review. Indem durch die zu einem bestimmten Zeitpunkt vorliegenden Resultate gegangen wird, versucht sich der Prüfende ein Bild über den aktuellen Stand der Arbeiten zu verschaffen.

Tabelle 13:	Qualitätssicherung

Werden Resultate durch eine Vernehmlassung von Fachvertretern abgenommen, wird diese Prüfung mittels eines schriftlichen Reviews durchgeführt.

Risikomanagement

Die Projektrisiken werden erstmalig im Projektauftrag aufgeführt und anschliessend, jeweils aktualisiert, im Projektstatusbericht und Phasenbericht weitergeführt.

Um Risiken beurteilen zu können, muss jedes Risiko in Bezug auf seine Eintretenswahrscheinlichkeit und der Auswirkungsgrad beurteilt werden. Hier werden die Variablen dazu festgelegt.

Bewertungsskale Eintretenswahrscheinlichkeit

Bewertung	Beschreibung der Eintretenswahrscheinlichkeit
1 = niedrig	unwahrscheinlich, bzw. unter 20%
2 = mittel	mässig wahrscheinlich, bzw. 20-50%
3 = hoch	hoch wahrscheinlich, bzw. über 50%

Tabelle 14:	Bewertungsskale Eintretenswahrscheinlichkeit

Bewertung	Auswirkung auf Projektergebnis	Auswirkung auf Termin	Auswirkung auf Kosten
1 = gering	Geringfügige Mängel	Bis 1 Monat, bzw. geringfügig	Keine
2 = mittel	Wesentliche Mängel	1 – 3 Monate bzw. wesentlich	5 – 20% bzw. wesentlich
3 = gross	Gravierende Mängel	Über 3 Monate bzw. gravierend	Über 20% bzw. gravierend

Tabelle 15:	Bewertungsskale Auswirkungsgrad

Aus diesen Werten ergeben sich anschliessend die Koordinaten um das Risiko in der Matrix abzubilden. Mit dem Pfeil (Bsp. Risiko 2) kann die Veränderung zur letzten Beurteilung aufgezeigt werden.

Risikomatrix

Abb. 4 -	Risikomatrix

Die identifizierten und bewerteten Projektrisiken werden analog der nachfolgenden Tabelle im Projektstatusbericht geführt. Für jedes Risiko werden eine oder mehrere Massnahmen geplant.

Nr.	Risikobeschreibung	EW	AG	RZ	Massnahmen	Verantw.	Termin
R1	IT-System nicht genügend performant	3	3	9	Performance-Tests	PL	01.01.2021
R2	Fachspezialist für Phase Konzept nicht verfügbar	2	2	4	Vereinbarung mit Stammorganisation	PL	12.12.2020
R3	Reorganisation in der Stammorganisation	3	1	3	Nachfolge sichern	Auftraggeber	31.12.2020
Legende: EW=Eintretenswahrscheinlichkeit: 1 Niedrig / 2 Mittel / 3 Hoch; AG=Auswirkungsgrad: 1 Gering / 2 Mittel / 3 Gross, RZ=Risikozahl: RZ = EW x AG

Tabelle 16:	Risikomatrix

Eskalationsvorgehen

Die Eskalation ist eine besondere Massnahme, die mit Vorsicht und möglichst nur in Ausnahmefällen angewendet werden sollte. Es ist immer erstrebenswert und im Rahmen eines Projekts von Vorteil, zuerst alle andere Massnahmen einer zielgerichteten Konfliktsbewältigung zu versuchen und seine eigene natürliche Kompetenz und Kommunikationsfähigkeit in die Waagschale zu werfen. Denn eine Eskalation zieht oft die nächste nach sich.

Das Vorgehen im Falle einer Konflikteskalation wird einmalig definiert und gilt für die gesamte Projektdauer. Das Vorgehen kann jedoch jederzeit angepasst werden.

Im Rahmen eines Projekts entsteht eine Eskalation aufgrund eines nicht gelösten Konflikts, oder eines Problems. Probleme, die durch die Projektführung mangels Kompetenzen oder ausreichender Mittel nicht gelöst werden können, werden als Eskalationen an die Projektsteuerung geleitet. Die Projektsteuerung behandelt diese mit der nötigen Priorität und Dringlichkeit.

Der Eskalationsprozess wird wertneutral und rollenspezifisch beschrieben. Er definiert die stufenweise Delegation eines aussichtslosen Konflikts, oder nicht zu lösenden Problems an eine höhere Projektinstanz: Von der Führungsebene, an die Steuerungsebene und anschliessend weiter innerhalb der Steuerungsebene an die nächst höhere Stufe.

Das beschrieben Vorgehen soll unter anderem definieren, unter welchen Umständen etwaige Hierarchiestufen übersprungen werden dürfen, und wann dies nicht angebracht sei.

Dokumentmanagement

Dokumentablage

Tools, Ablageort, Zugriffsverwaltung

Namenskonventionen

Damit projektbezogene Dokumente eindeutig und einfach identifiziert werden können, werden die folgenden Namenskonventionen für Dateinamen angewendet:

Projektname-Dokumentbezeichnung.Dateityp

Beispiel:

HMH-Projektauftrag.doc

Versionen von Dokumenten

Änderungen an Dokumenten sollen im Änderungsverzeichnis des Dokuments aufgeführt werden.

Verwendung von Versionsnummern:

Versionsnummern V0.1, V0.2, V0.3….V0.9 bezeichnen Versionen von Dokumenten in Arbeit.

Versionsnummer V1.0 ist die erste abgenommene Version des Dokuments.

Versionsnummer V1.1 ist die erste geänderte Version nach der Abnahme.

Versionsnummer V2.0 ist die zweite abgenommene Version des Dokuments.

Versionsmanagement

Mit Microsoft PowerPoint anpassbar (rechte Maustaste – Präsentation-Objekt – Open)

Abb. 5 -	Grafik Versionsmanagement

Dokumente mit Zeitbezug

Dokumente mit einem klaren Zeitbezug enthalten das Datum im Dateinamen.

Beispiel eines Sitzungsprotokolls:

HMH-Protokoll-Kernteammeeting-2020-12-05.doc

Allerdings kann auch der Zeitbezug als Version genutzt werden. Es macht wenig Sinn beides – also die Version und den Zeitbezug – zu kombinieren.

Bei Verwendung des Datums im Dateinamen wird immer das Format JJMMTT (oder JJJJ-MM-TT) verwendet, damit Dokumente in Verzeichnissen sortiert angezeigt werden. Wird das Datum im Namen führend verwendet, werden alle Dokumente nach Datum gezeigt. Wird hingegen der Dateiname führend verwendet, werden die Dokumente alphabetisch, und pro Dokument nach Version (Datum) angezeigt.

Empfehlung zur Verwendung des Zeitbezugs:

In der Regel hat sich die Verwendung des Zeitbezugs als Version in den meisten Fällen etabliert. Da die Dokumente für gewöhnlich immer nach Datum sortiert werden können hat sich in der Praxis gezeigt, dass der führende Namen mehr Nutzen bringt (Dokumentname JJMMTT.xxx) als umgekehrt. Andernfalls ist nämlich eine alphabetische Sortierung nicht möglich.

Ferner kann heute in den meisten Fällen wieder auf die Kurzform JJMMTT umgestellt werden, wie es seinerzeit vor der Jahrtausendwende üblich war.

Projektname-Dokumentbezeichnung JJMMTT.Dateityp

Beispiel:

HMH-Projektauftrag 211126.doc

HMH-Projektauftrag 211205.doc

Änderungsmanagement

Mit Microsoft PowerPoint anpassbar (rechte Maustaste – Präsentation-Objekt – Open)

Abb. 6 -	Grafik Änderungsmanagement