46
Projektmanagement Informations- und Berichtswesen Projekthandbuch Projektkontrolle und steuerung Oktober 2012, Robert Kolb

Projektmanagement - pmcm.frox.compmcm.frox.com/Projektmanagement_2.pdf · Projektmanagement Informations- und Berichtswesen Projekthandbuch ... Schulungsunterlagen Wartungsunterlagen

Embed Size (px)

Citation preview

Projektmanagement

Informations- und Berichtswesen

Projekthandbuch

Projektkontrolle und –steuerung

Oktober 2012, Robert Kolb

FROX blau

Logo grau

Balken grau

2

Themen

Informations- und Berichtswesen

Dokumentation

Projektkontrolle und -steuerung

Projektabschluss, Debriefing

3

Lernziele

Sie können erklären, was unter einem Projekt-Informationskonzept zu

verstehen ist

Sie können den Zweck des Projekthandbuches erklären

Sie können den Zweck von Projektkontrolle und -steuerung erläutern

Sie kennen Methoden zur Leistungs- und Stundenkontrolle

4

Informations- und Berichtswesen

Information ist wie ein

Wanderpokal. Den darf auch

niemand für sich behalten.

5

Projekt-Informationskonzept – Was bedeutet das?

Unter dem Projekt-Informationskonzept verstehen wir:

Transparentmachen und Systematisierung des Informationsflusses oder

Informationsbeziehungen

Erstellen eines Unterlagenkonzeptes

Methoden und Vorgehensmuster für die Information

6

Ein Projekt-Informationskonzept – Wozu?

Üblicherweise wird in einem Projekt zu wenig und zu spät informiert.

Ein Informationskonzept hält eher dazu an, frühzeitig und regelmässig zu

informieren.

In der Art und Weise, wie mit Informationen umgegangen wird, hat jede

Organisation ihre Gepflogenheiten. Das Informationskonzept sollte

deshalb zur gängigen Informationskultur kompatibel sein und diese

konkretisieren.

Das Informationskonzept dient dem Systematisieren von Information und

Dokumentation, damit nicht etwas vergessen oder unterlassen wird.

7

Ist Information eine Hol- oder Bringschuld?

Vereinbaren Sie in Ihrem Team folgende Spielregeln:

Jeder holt sich eigenverantwortlich selbst alle notwendigen

Informationen. Es ist Pflicht zu fragen. Die Ausrede "Das hat mir keiner

gesagt" gilt nicht.

Jeder sorgt von sich aus dafür, dass alle anderen im Team alle

notwendigen Informationen erhalten. Zurückhalten von Information gilt

als Egoismus und soll es im Team nicht geben.

8

Projektmeetings

Regelmässige Projektmeetings sind ausserordentlich wichtig zum

Informationsaustausch und bilden Fixpunkte in der Projektarbeit.

Lassen Sie die Mitarbeiter in den Projektmeetings berichten:

– Das machen wir zur Zeit

– So weit sind wir schon

– Das kann man schon verwenden oder ausprobieren

(wichtigster Punkt für die Entwickler)

– Das haben wir noch vor uns

– Hier brauchen wir Hilfe oder Informationen von den anderen

9

Praxistipps

Falsch aufbereitete Information kann mehr schaden als nützen.

Deshalb soll Umfang und Form der Information empfängergerecht

aufbereitet werden.

Achten Sie auf zurückgezogene oder Home Office Mitarbeiter,

auch sie müssen in das Informationsnetz eingebunden werden.

Betreiben Sie eine offene Informationspolitik, das verhindert

Gerüchte.

Informieren Sie so viel als möglich mündlich, aber machen Sie

jeweils ein kurzes Protokoll.

10

Informationsweitergabe

Stellen Sie sicher, dass in Ihrem Projekt Folgendes geregelt ist:

Klassifizierung von Information in interne und externe (public)

Wer entscheidet über die Klassifizierung bei Unklarheit

Wer darf Informationen herausgeben und an wen

Welche Information darf herausgegeben werden

Wer entscheidet bei Unklarheiten über die Herausgabe

11

Interne Informationen

Interne Informationen sind z.B.:

Schätzungen

Berechnungsgrundlagen für Offerten

Arbeitsaufträge

Pläne

Verträge

Testunterlagen

Reviewberichte

Statusberichte der Mitarbeiter

Problemdokumentationen

12

Externe Informationen

Externen Informationen sind z.B.:

Spezifikation (Pflichtenheft)

Präsentationen

Handbücher

Projektstatusberichte

Meilensteindokumente

Fehlerprotokolle

Änderungsprotokolle

Abschlussberichte

13

Projektstatusbericht

In Ihrem Projektstatusbericht sollten folgende Informationen enthalten sein:

Erledigte Arbeitsaufträge

Pendente Arbeitsaufträge

Noch nicht begonnene Arbeitsaufträge

Verbrauchte Ressourcen (Material, Geld...)

Erreichte Termine und Meilensteine sowie Verzögerungen

Soll/Ist-Zustand

Probleme und mögliche Probleme (Risiken)

Wo haben Sie Entscheidungsbedarf?

14

Problembericht

Erstellen Sie bei Problemen einen Bericht, der zumindest Folgendes

enthält:

Beschreibung des Problems (z.B. Engpässe, Konflikte, Abweichungen..)

Lösungsvorschläge

Notwendige Entscheidungen

– Was ist zu entscheiden?

– Bis wann ist zu entscheiden?

– Durch wen ist zu entscheiden?

Dringlichkeit

Aufwand und Termine für die Lösung des Problems

Erwartete Konsequenzen bei Ausbleiben oder Verzögerung der Lösung

15

Dokumentation

„Lesen macht einen Menschen

vielseitig,

Verhandlungen machen ihn

geistesgegenwärtig,

Schreiben genau.“

16

Grundlegendes zur Projektdokumentation

Verantwortlich für die lückenlose Projektdokumentation ist der

Projektleiter

Eine konsequente Projektdokumentation gewährleistet einen schnellen

Zugriff auf verfügbare Unterlagen für alle Projektbeteiligten

Die Aktenordnung sollte so früh als möglich festgelegt werden, um

Wildwuchs zu vermeiden

Jeder Bearbeiter dokumentiert seine Arbeitsergebnisse

Jeder Bearbeiter ist zur Aktualisierung verpflichtet

17

Unterschiede zwischen Bericht und Dokumentation

Der Bericht ist eine Beschreibung des Sachstandes zu einem

bestimmten Zeitpunkt (Momentaufnahme)

Die Dokumentation erfasst nachvollziehbar alle bedeutsamen Rahmen-,

Planungs-, Beschluss- und Ergebnisdaten

Die Dokumentation ist somit ein Nachschlagewerk während und nach

dem Ende des Projekts

Die Dokumentation ermöglicht, falls erforderlich, einen

Projektleiterwechsel und den Transfer von Projekterfahrungen in

Folgeprojekte

18

Unterschiede zwischen Projekt- und Produktdokumentation

Die Projektdokumentation enthält die Grundlagen, weshalb das Produkt

entstanden ist (wer hat was entschieden und verantwortet)

Die Projektdokumentation zeichnet die Entstehung des Produktes

nachvollziehbar nach (wie wurde gearbeitet, worauf beruhen die

Entscheide)

Die Produktdokumentation beschreibt das Produkt in seinem Aufbau, in

seiner Funktionalität und in seiner Handhabung

19

Projekthandbuch (1)

Ziel des Projekthandbuchs ist es, die Zusammenarbeit möglichst

reibungslos und effizient zu gestalten.

Das Projekthandbuch enthält die sinnvollen und nötigen

organisatorischen Informationen und Regelungen für die

Zusammenarbeit

Es dient zudem als Einstiegshilfe für neue Projektmitarbeiter

(= Project Master Boot Record)

Für die Erstellung und Pflege des Projekthandbuchs ist der Projektleiter

verantwortlich

20

Projekthandbuch (2)

Inhaltsverzeichnis eines Projekthandbuchs:

Projektbeschreibung (Auftraggeber, Ziel des Auftrages)

Organisationsstruktur (technische und kommerzielle Projektleitung)

Projektbeteiligte (Mitarbeiter, Kontakte beim Kunden etc.)

Schriftverkehr (Templates)

Informationsaustausch (Meetings)

Aktenordnung (Ablagesystem)

Projektdokumentation (Anweisungen zur Erfassung und Pflege)

Organisation des Change Managements

Organisation des Configuration Managements

21

Praxistipp

Aufwand und Nutzen für die Erarbeitung und Pflege eines

Projekthandbuchs müssen im angemessenen Verhältnis stehen

Ein Minimal-Projekthandbuch enthält:

– Projektbeschreibung, Projektziele (Vision)

– Grobe Organisationsstruktur

– Liste der Projektbeteiligten

– Schriftverkehr

– Aktenordnung (wo liegt die Doku, wo der Code)

– Change Management

22

Beispiele einer Projektdokumentation

Projekthandbuch

Ablagesystem

Dokument-Namensgebung

Dokumentvorlagen

Memos

Pendenzenliste

Beschlussliste

Änderungen (Change Requests)

Lieferprotokoll

Abnahmeprotokoll

23

Beispiele einer Produktdokumentation

Benutzerhandbuch

Administrationshandbuch

Installationshandbuch

Release Notes

Fehler (Bug Reports)

Schulungsunterlagen

Wartungsunterlagen

24

Projektkontrolle und -steuerung

25

Grundlagen der Projektkontrolle und -steuerung

Grundlage ist die Projektplanung, welche selber auch falsch sein kann,

wenn sie nicht nachgeführt ist

Es kann nicht feiner kontrolliert werden, als die Gliederung der

Projektaufgabe vorgenommen wurde

26

Projektkontrolle versus Projektsteuerung

Die Projektkontrolle bezweckt das rechtzeitige Feststellen von

Abweichungen gegenüber den geplanten

– Terminen

– Kosten (Aufwände)

– Systemzielen und Vorgehenszielen

Die Projektsteuerung umfasst diejenigen Massnahmen, welche das

Projekt auf Zielkurs halten oder bei Abweichungen wieder darauf

zurückbringen.

27

Formen der Projektkontrolle

Regelmässige Abfrage des Projektstandes

Formalisierte und regelmässige Projektfortschrittsberichte

Regelmässige Projektbesprechungen

Abfrage der Fertigstellungstermine

Abfrage des Restaufwandes

Unregelmässige Gespräche mit den Bearbeitern

Erfassen der verbrauchten Mitarbeiterstunden

28

Es ist eine Sache der Verhältnismässigkeit

Der Umfang des Kontrollsystems muss der Grösse und der Komplexität

des Projektes angepasst werden

Erstellen Sie allenfalls einen Projektkontrollplan, der aufzeigt, wann und

wie Kontrollen durchgeführt werden

Bei kleinen Projekten reicht eventuell eine Checkliste mit den wichtigsten

Soll-/Ist-Terminen für die massgebenden Aktivitäten

Bei Projekten mit zahlreichen zeitkritischen Aktivitäten sollte der Einsatz

eines Projektmanagementtools geprüft werden

29

Kosten- und Stundenkontrolle

Bei IT-Entwicklungsprojekten sind die beiden Faktoren Kosten und

Zeitaufwand eng miteinander verknüpft, da im Wesentlichen nur

Personalkosten zum Tragen kommen

Erfassen Sie die verbrauchten Stunden regelmässig und mindestens

wöchentlich (z.B. beim regelmässigen Projektmeeting)

Tragen Sie die Soll- und Ist-Stunden gegeneinander auf (z.B. in Excel)

und stellen Sie den Stundenverbrauch graphisch dar

0

200

400

600

800

1000

1200

1400

1.

Wo

2.

Wo

3.

Wo

4.

Wo

5.

Wo

6.

Wo

7.

Wo

8.

Wo

9.

Wo

10.

Wo

11.

Wo

30

Terminkontrolle

Basis für die Terminkontrolle ist der Terminplan

Terminüberschreitungen lassen sich oft zurückführen auf:

– Bearbeitungszeiten für einzelne Vorgänge wurden zu optimistisch

geschätzt

– Zusätzliche, in der Planung nicht berücksichtigte Arbeiten, sind

notwendig

– Änderung des Projektziels durch den Auftraggeber

– Verspätetes Eintreffen von Daten und Informationen, die für die

Bearbeitung notwendig sind

Ist der Endtermin mit Sicherheit nicht mehr einzuhalten, ist der

Auftraggeber (schriftlich) zu informieren

31

Leistungskontrolle - Weshalb und wie?

Die Tatsache, dass Kosten bzw. Stunden angefallen sind, ist noch kein

Indiz dafür, dass auch eine äquivalente Leistung erbracht wurde.

Deshalb ist eine Leistungskontrolle notwendig.

Um Informationen zur Beurteilung des Projektstandes zu ermitteln, gibt

es folgende Möglichkeiten:

– Informelle Befragung

– Einzelgespräch

– Projektteam-Besprechung

– Fortschrittsbericht

– Build and Smoke Test

32

Leistungskontrolle durch Fortschrittsberichte

Bei grösseren Projekten mit mehreren Bearbeitern sollten Sie

regelmässig (z.B. monatlich) Fortschrittsberichte einfordern, so genannte

Monatsberichte.

Durch schriftliche Auskünfte zum Projektstand sind verlässlichere

Aussagen zu erwarten als bei mündlichen Angaben.

33

Leistungskontrolle durch Build and Smoke Test

Eine Möglichkeit zur Leistungskontrolle bildet die

Methode „Build and Smoke Test“

Bei dieser Methode wird in regelmässigen Abständen

(z.B. wöchentlich oder zweiwöchentlich) ein

kompletter Satz der Software erstellt und auf einem

Testsystem installiert. (Build)

Anschliessend werden die erwarteten Funktionen

überprüft. (Smoke)

Mit dieser Methode lässt sich der Projektstand

bezüglich Implementation recht gut abschätzen.

Mehr Info z.B. unter:

http://www.projectperfect.com.au/info_build_smoke.php

34

Projektsteuerung

Korrekte Zielformulierungen erlauben erst eine richtige Kontrolle und

Steuerung

Periodische Koordinationssitzungen des Projektteams zum raschen

Beschliessen von Massnahmen

Erstellen Sie ein Protokoll (Pendenzenliste und Beschlussprotokoll) von

Projektmeetings

Ergänzen oder ändern Sie die Ziele nur, wenn absolut nötig und nur mit

(schriftlicher) Genehmigung des Auftraggebers

35

Scrum: Steuerung aus nicht-agilen Prozessen

Handeln Sie die Erwartungen im Vorfeld aus (siehe Projekt Kick-off)

Passen Sie die Berichterstattung an die derzeitigen Erwartungen an.

Je nach Art des überliegenden Prozesses müssen Sie bestimmte

Artefakte liefern, welche in Scrum nicht üblich sind. Weigern Sie sich

nicht, diesen Erwartungen zu entsprechen.

Versuchen Sie nach Möglichkeit die Erwartungen zu ändern, indem Sie

für agile Methoden besser geeignete Informationen bereitstellen.

Wenn möglich, beziehen Sie den Steuerungsbeauftragten in Ihren

Prozess ein. Geben Sie dem Steuerungskommitee die Gelegenheit, bei

den regelmässigen Besprechungen dabei zu sein (z.B. Sprint Review)

36

Massnahmen bei Abweichungen

Aufwand reduzieren (Funktionalität auf später verschieben)

Kapazität erhöhen

Abläufe und Termine anpassen

Widerstehen Sie der Versuchung die Qualität zu senken, um den Aufwand zu

reduzieren. Dieser Schritt kann später zu massiv höheren Aufwänden und

Kosten führen.

37

Scrum: Sprint Regeln (1)

Sprints nicht verlängern

Sprint Planung und Release Planung wird einfacher, da Teams besser

lernen, wieviel in einen Sprint passt und die Ende der Sprints sind

vorhersehbar.

Ziel während des Sprints nicht ändern

Das Umdirigieren von Teams während des Sprints führt automatisch zu

einer "abnormal sprint termination", quasi der Notbremse von Scrum und

sollte nur in Ausnahmesituationen erfolgen.

38

Scrum: Sprint Regeln (2)

Erreichte Veränderung zählt

Nicht der Plan ist wichtig, sondern die durch den Sprint erreichte

Veränderung.

Minimieren von Variation

Je weniger unterschiedliche Tasks ein Sprint aufweist, desto höher ist

die Produktivität.

39

Immaterielle Boni für gute Leistungen des Teams

Um das Team für seine gute Arbeit zu belohnen, sind immaterielle Boni

eine interessante Möglichkeit.

Team darf Dinge am Produkt tun, welches es schon lange einmal tun

wollte.

Team darf etwas neues für die Entwicklungsumgebung ausprobieren,

z.B. neue Test-Tools, Continous Integration, Versionsverwaltung, Bug

Tracking

40

Projektabschluss

Lieber ein Ende mit Schrecken als

ein Schrecken ohne Ende.

41

Aspekte eines Projektabschlusses

Produktübergabe

Wartungsvereinbarung

Reintegration der Projektmitarbeiter in die Linie

Qualifikationsgespräch

Ressourcenauflösung

Nachkalkulation

Manöverkritik als Lernchance ermöglichen

Information nach aussen (Öffentlichkeitsarbeit)

Verdanken der Mitarbeit, wenn möglich mit Abschlussfeier

Motivation für neue Projekte schaffen

Dechargé des Projektleiters durch den Auftraggeber

42

Der Projektabschluss ist eine Phase

Wie aus den Aspekten eines Projektabschlusses abgeleitet werden

kann, ist der Projektabschluss nicht ein Zeitpunkt, sondern eine Phase.

Die Länge dieser Phase ist von der Grösse des Projekts abhängig.

Planen Sie den Projektabschluss auch angemessen ins Budget ein.

Selbst für kleinere Projekte (z.B. 3 Mitarbeiter während 2-3 Monaten)

sind mindestens fünf Personentage einzusetzen.

43

Debriefing

Wiederholte Fehler

sind ein Kostentreiber

– und eine

Motivationsbremse

44

Lessons Learned

Analog zum Kick-off Meeting hat auch das Debriefing eine besondere

Bedeutung und soll dazu genutzt werden, Rückschau zu halten und dem

Projektende eine würdige Note zu geben.

In der Rückschau geht es darum, das Vergangene kritisch zu betrachten

und Lehren für die Zukunft daraus abzuleiten, was noch besser gemacht

werden kann.

Es geht beim Debriefing jedoch nicht um eine Endabrechnung mit

Anschuldigungen oder Rechtfertigungen!

Planen Sie im Debriefing auch einen geselligen Teil ein, bei dem die

Projektmitarbeiter für ihren geleisteten Einsatz symbolisch entschädigt

werden.

Debriefings können auch nach Meilensteinen stattfinden.

45

Aufgaben für das Selbststudium

Skript

Basiswissen SW-PM, Kapitel 5.1.3

Basiswissen SW-PM, Kapitel 5.3

Basiswissen SW-PM, Kapitel 10

46

Fragen und Antworten