projektmanagement - pmcm.frox.compmcm.frox.com/projektmanagement_2.pdf · projektmanagement...
TRANSCRIPT
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
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
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.
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