Migrationsl ¨osung f ¨ur den netzintegrierten Anrufbeantworter der ...

Migrationslösung für den
netzintegrierten Anrufbeantworter der
Imaginary Networks AG
Transfernachweis im Rahmen der Fortbildung
zum Projektmanagement-Fachmann
(GPM/IPMA)
Danilo Kempf
14. Mai 2008
08-045

Inhaltsverzeichnis
Inhaltsverzeichnis i
Vorbemerkungen v
Realitätsbezug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Zeitliche Lage und Projektkalender . . . . . . . . . . . . . . . . . . . . . . v
Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1 Projekt und Projektziele 1
1.1 Projektbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Projektsteckbrief . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Eigene Position und Rolle im Projekt . . . . . . . . . . . . . . 4
1.2 Zielbeschreibung und Zielhierarchie . . . . . . . . . . . . . . . . . . 4
1.2.1 Zieldefinition des Auftraggebers . . . . . . . . . . . . . . . . 4
1.2.2 Präzisierung und Operationalisierung . . . . . . . . . . . . . 5
1.2.3 Zielhierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Zielbeziehungen und Zielkonflikte . . . . . . . . . . . . . . . . . . . . 9
2 Projektumfeld und Stakeholder 13
2.1 Projektumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Umfeldfaktoren . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2 Grafische Darstellung des Projektumfeldes . . . . . . . . . . 16
2.2 Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Stakeholderportfolio und Stakeholdersteuerung . . . . . . . . . . . . 19
3 Risikoanalyse 23
3.1 Erfassung, Klassifizierung und Beschreibung der Risiken . . . . . . . 23
3.2 Bewertung der Risiken . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Maßnahmen zur Risikobegegnung . . . . . . . . . . . . . . . . . . . 28
4 Projektorganisation 33
4.1 Art der Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Wahl einer Projektorganisation . . . . . . . . . . . . . . . . . . . . . 33
4.2.1 Stammorganisation . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.2 Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.3 Grafische Darstellung der Projektorganisation . . . . . . . . . 35
4.3 Eskalation und Entscheidungsgremien . . . . . . . . . . . . . . . . . 36
08-045 Kempf Danilo.pdf i

INHALTSVERZEICHNIS
5 Phasenplanung 37
5.1 Beschreibung der Projektphasen . . . . . . . . . . . . . . . . . . . . 37
5.2 Meilensteinliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Veranschaulichung der Projektphasen . . . . . . . . . . . . . . . . . 39
6 Projektstrukturplan 41
6.1 Darstellung und Codierung des PSP . . . . . . . . . . . . . . . . . . 41
6.2 Projektmanagement im PSP . . . . . . . . . . . . . . . . . . . . . . 44
6.2.1 Projektplanung erstellen . . . . . . . . . . . . . . . . . . . . 44
6.2.2 begleitendes Projektmanagement durchführen . . . . . . . . . 45
6.2.3 Projektdokumentation erstellen . . . . . . . . . . . . . . . . . 45
6.3 Arbeitspaketbeschreibungen . . . . . . . . . . . . . . . . . . . . . . 46
6.3.1 AFP-Schnittstelle dokumentieren (1.1.1) . . . . . . . . . . . . 47
6.3.2 Softwarearchitektur definieren (1.2.3) . . . . . . . . . . . . . 48
6.3.3 Analysieren, profilieren, Probleme beseitigen (1.4.2) . . . . . . 49
7 Ablauf- und Terminplanung 51
7.1 Vorgangsliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.1 Dauer der Arbeitspakete . . . . . . . . . . . . . . . . . . . . 51
7.1.2 Anordnungsbeziehungen ermitteln . . . . . . . . . . . . . . . 53
7.2 Netzplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2.1 Einsatz der Netzplantechnik . . . . . . . . . . . . . . . . . . 56
7.2.2 Pufferzeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.2.3 Terminplanung . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.3 Anordnungsbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3.1 Normalfolge . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.2 Anfangsfolge . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.3 Normalfolge mit zeitlichem Versatz . . . . . . . . . . . . . . . 63
8 Einsatzmittel- und Kostenplanung 65
8.1 Einsatzmittelklassen und Einsatzmittelbedarf . . . . . . . . . . . . . . 65
8.1.1 Mitarbeiterqualifikationen . . . . . . . . . . . . . . . . . . . . 65
8.1.2 Weitere Einsatzmittel . . . . . . . . . . . . . . . . . . . . . . 66
8.1.3 Einsatzmittelverfügbarkeit . . . . . . . . . . . . . . . . . . . 67
8.1.4 Einsatzmittelbedarf . . . . . . . . . . . . . . . . . . . . . . . 68
8.2 Auslastungsprofil für kritische Einsatzmittel . . . . . . . . . . . . . . . 72
8.2.1 Problematik . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.2.2 kapazitätstreuer Kapazitätsausgleich . . . . . . . . . . . . . . 74
8.2.3 termintreuer Kapazitätsausgleich . . . . . . . . . . . . . . . . 75
8.2.4 gewählte Variante . . . . . . . . . . . . . . . . . . . . . . . . 76
8.3 Projektkosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.3.1 Kostenarten und Kostenstellen . . . . . . . . . . . . . . . . . 76
8.3.2 Ermittlung der Projektkosten . . . . . . . . . . . . . . . . . . 77
8.3.3 Kostengang- und Kostensummenlinie . . . . . . . . . . . . . 78
9 Soziale Kompetenz 81
ii Danilo Kempf

9.1 Teamarbeit (Teambildung und Konflikte) . . . . . . . . . . . . . . . . 81
9.1.1 Johari-Fenster . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.1.2 Teamentwicklung . . . . . . . . . . . . . . . . . . . . . . . . 83
9.2 Führung (Führungsstile und Entscheidungsfindung) . . . . . . . . . . 87
9.3 Kommunikation im Projekt (Meetings, Berichte, Beteiligungen) . . . . . 88
10 Wahlelemente 91
10.6 Konfiguration und Änderungen . . . . . . . . . . . . . . . . . . . . . 91
10.6.1 Konfigurationsmanagement . . . . . . . . . . . . . . . . . . . 91
10.6.2 Änderungsmanagement . . . . . . . . . . . . . . . . . . . . 93
10.7 Projektstart und Projektende . . . . . . . . . . . . . . . . . . . . . . 95
10.7.1 Projektstart . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10.7.2 Projektende . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
10.9 Projektberichtswesen und Projektdokumentation . . . . . . . . . . . . 100
10.9.1 Berichtswesen . . . . . . . . . . . . . . . . . . . . . . . . . 100
10.9.2 Projektdokumentation . . . . . . . . . . . . . . . . . . . . . . 103
Anhang 105
Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Abbildungsverzeichns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Anlagen 109
vollständige Vorgangsliste . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
08-045 Kempf Danilo.pdf iii

Vorbemerkungen
Realitätsbezug
Das in diesem Transfernachweis geschilderte Projekt ist nicht vollständig fiktiv,
sondern basiert auf einem durchaus realen Projektverlauf. Auf Wunsch
des Auftraggebers wurden jedoch Namen, Daten und Kennzahlen geändert,
um eine Identifizierung der Beteiligten zu erschweren.
Für die Veröffentlichung im Internet wurden – sieht man von diesen Vorbemerkungen
sowie der Korrektur einiger Tippfehler ab – keine Änderungen
an diesem Transfernachweis vorgenommen, es handelt sich also um genau
den Transfernachweis, den ich zur Zertifizierung eingereicht habe.
Das Feedback der PM-ZERT-Assessoren habe ich unter http://www.
nullpointer.de/learn/pm/transfer gesammelt.
Zeitliche Lage und Projektkalender
Für alle Abschnitte dieses Transfernachweises will gelten, daß sie nachträglich
verfaßt sind. So sind auch in den wiedergegebenen frühen Planungsschritten
bereits die Resultate späterer Planungsschritte bekannt. Dies bedeutet also unter
anderem, daß bereits in der Phasenplanung vorgreifend auf die Ergebnisse
der Termin- und der Einsatzmittelplanung eingegangen wird.
Das hier beschriebene Projekt begann am 1. November 2007 und endete
am 11. April 2008, umspannte also den Jahreswechsel. Dabei ist zu beachten,
daß die Firma Telco-Soft über den Jahreswechsel grundsätzlich zwei Wochen
Betriebsferien einlegt. Dies ist in den Planungsschritten berücksichtigt – es
wird jedoch im Folgenden nicht in jedem Fall gesondert darauf hingewiesen.
Darüber hinaus gilt für den Projektkalender eine übliche Arbeitswoche von –
jeweils einschließlich – Montag bis Freitag.
Konventionen
Der Text dieses Transfernachweises ist nach folgenden typografischen Konventionen
formatiert:
08-045 Kempf Danilo.pdf v

VORBEMERKUNGEN
Tabellenüberschriften und Gliederungseinheiten sind in serifenloser
Schrift farbig hervorgehoben ausgezeichnet. Gleiches gilt für sporadisch
im Text auftauchende Schlüsselworte.
Querverweise werden im Text farbig und fettgedruckt hervorgehoben. In
der PDF-Version des Dokumentes sind die Querverweise aktiv und führen
durch Anklicken direkt zur referenzierten Textstelle. Beispiel: 2 Projektumfeld
und Stakeholder 〈S. 13〉.
Projektziele werden als ausgefülltes Rechteck mit einer eindeutigen Kennung
wiedergegeben, beispielsweise E2 .
Umfeldfaktoren, Stakeholder und Projektrisiken werden in den jeweiligen Analyseschritten
in Form eines Kreises mit einer eindeutigen Nummer aufgezeichnet.
Beispiel: 2 .
Eigenschaftswerte, wie beispielsweise die Art von Zielbeziehungen oder die
Einstufung von Stakeholdern nach Betroffenheitsgrad werden durch ein umrandetes
Rechteck gekennzeichnet, etwa wie AN oder +++ .
Teilaufgaben und Arbeitspakete werden durch den PSP-Code identifiziert
und farblich hervorgehoben und in Schrägschrift wiedergegeben. Beispiel:
1.6.4 Projektdokumentation erstellen.
Meilensteine sind durch ihre eindeutige Nummer und die vorangestellte
Raute kenntlich gemacht. Beispiel: 1.
Persönliche Anmerkungen, die nicht unmittelbar zum primären Inhalt des
Transfernachweises gehören, mir aber dennoch wichtig erschienen, sind in
Form eines solchen Anmerkungs-Kastens eingefügt.
vi Danilo Kempf

Projekt und Projektziele 1
1.1 Projektbeschreibung
1.1.1 Ausgangssituation
Die Telco-Soft GmbH entwickelt und vertreibt professionelle Telekommunikationslösungen
im ISDN- sowie im NGN-Bereich. Ein Kernprodukt der
Telco-Soft GmbH ist die TelAPI , eine Schnittstelle, die Softwareapplikationen
den Zugang zum ISDN-Netz und zu diversen NGN-Netzen ermöglicht und
Applikationsentwicklern einfache Zugriffsmöglichkeiten auf netzspezifische
Dienstmerkmale und auf technische Finessen wie Audio- und Videokonferenzen
bietet. Diese Schnittstelle dient vielen Drittherstellern als Basis für eigene
Produkte.
Die AFP GmbH bot in der Vergangenheit mit der AFP NetStar eine ähnliche,
wenngleich technisch inkompatible Schnittstelle mit vergleichbarem Funktionsumfang
an, die gleichermaßen einigen Drittanbietern als Produktbasis
diente. Ende des Jahres 2006 wurde die AFP GmbH insolvent und mußte
dementsprechend ihre Tätigkeit einstellen. Im Zuge des Insolvenzverfahrens
wurde der Software-Quelltext diverser AFP-Produkte von der Telco-Soft
GmbH erworben. Im Laufe des Jahres 2007 wurden zwei ehemalige Mitarbeiter
der AFP GmbH von der Telco-Soft GmbH eingestellt.
Die Imaginary Networks AG ist ein großer, europaweit agierender Telefonie-
Dienstanbieter für Sprach-, Internet- und Datendienste mit mehr als einer Million
Privat- und Geschäftskunden. Der netzintegrierte Anrufbeantworter im
intelligenten Netz der Imaginary Networks AG ist eine Softwarelösung, die
auf der ehemals von der AFP GmbH vertriebenen Telefonieschnittstelle basiert.
Durch die Insolvenz der AFP GmbH bedingt besteht für die Imaginary
Networks AG ein erheblicher Unsicherheitsfaktor in der Nutzung dieser
Schnittstelle. Sollten künftig technische Schwierigkeiten auftreten oder Erweiterungsbedarf
bestehen, wäre eine Problemlösung äußerst schwer herbeizuführen.
Die Telco-Soft GmbH als neuer Eigentümer des NetStar-Quelltextes
sieht sich außer Stande, diesen langfristig zu pflegen. Nach intensiven Gesprächen
zwischen Imaginary Networks und Telco-Soft wurde entschieden,
die netzintegrierte Anrufbeantworterlösung künftig auf der durch die Telco-
Soft GmbH vertriebenen Schnittstelle aufsetzen zu lassen.
08-045 Kempf Danilo.pdf 1

1 PROJEKT UND PROJEKTZIELE
Dem Leitsatz never change a running system folgend wurde gleichsam entschieden,
daß eben nicht die Anrufbeantworter-Applikation selbst, die immerhin
den Betrieb mehrerer Zehntausend Mailboxen sicherstellt, angepaßt
wird, sondern das stattdessen eine schlanke Adaptionsschicht geschaffen
wird, die als Mittler zwischen AFP- und Telco-Soft-Schnittstelle dient.
Somit wird die Anrufbeantworter-Lösung in Zukunft weiterhin die AFP-
Schnittstelle nutzen, die jedoch erheblich verschlankt wird und nur noch die
Anfragen der Applikation in angepaßter Form an die Telco-Soft-Schnittstelle
weiterleitet.
1.1.2 Projektsteckbrief
Dieser Projektsteckbrief gibt markante Eckdaten des Projektes in reduzierter
und zusammengefaßter Form wieder. Auf die einzelnen Punkte des Steckbriefes
wird in den folgenden Abschnitten des Transfernachweises detailliert
eingegangen.
Projekt
Schnittstellenmigration/netzintegrierter Anrufbeantworter
Projektart
Entwicklungsprojekt
Projektinhalt
Migration des netzintegrierten Anrufbeantworters der Imaginary Networks
AG auf die TelAPI-Software der Telco-Soft GmbH
Auftraggeber
Geschäftsführung der Telco-Soft GmbH
Kunde
Imaginary Networks AG
Projektumfeld
Firma Telco-Soft GmbH, Würzburg mit bestehendem internen Mitarbeiterstamm
Termine
Projektbeginn 1. November 2007, Dauer 107 Tage, Projektende 11. April
2008
Projektbeteiligte
Im Folgenden sind die direkt am Projekt beteiligten Personen mit ihren
jeweiligen projektbezogenen Rollen wiedergegeben.
Auftraggeber
Burkhard Römer und Michael Sieber, Geschäftsführer der Telco-
Soft GmbH GmbH
Projektleiter
Danilo Kempf (80%)
2 Danilo Kempf

PROJEKTBESCHREIBUNG 1.1
Mitarbeiter/Entwicklung
Martin Riedel, Thomas Ernemann, Michael Walm, Sören Schneider,
Danilo Kempf (20%)
Mitarbeiter/Test und Qualitätssicherung
Torben Rahlich, Jens Wippel, Lothar Karlson
Mitarbeiter/Dokumentation
Jürgen Kurzmann
Machtpromotoren
Herr Michael Sieber und Herr Burkhard Römer (Geschäftsführer der
Telco-Soft GmbH und Projektauftraggeber)
Fachpromotor
Herr Martin Riedel (ein Entwickler der TelAPI-Schnittstelle, Initiator des
im Projekt umgesetzten Lösungsansatzes)
Risiken
Folgende Risiken werden als projektsignifikant eingeschätzt:
Ziele
• Widerstand durch die ehemaligen Mitarbeiter der AFP GmbH
• mangelnde Akzeptanz der Lösung beim Kunden
• CeBIT-Termin möglicherweise nicht haltbar
• Projektabschlußtermin möglicherweise nicht haltbar
• Umsetzbarkeit nicht sichergestellt
• Qualität nicht ausreichend
• Überlastung des Projektteams
• Überlastung der Laborkapazität
Oberziel für das Projekt ist:
• Schaffung einer Adapterlösung von AFP NetStar auf Telco-Soft TelAPI
Es existieren folgende Ergebnisziele:
• AFP-Schnittstelle ist dokumentiert
• eine Adaptionssoftware von AFP- auf Telco-Soft-Schnittstelle ist
implementiert
• die Software erfüllt alle Qualitätskriterien
• eine demonstrierbare Version ist bist zur CeBIT 2008 verfügbar
• die ehemaligen Mitarbeiter der AFP GmbH sind in das Team integriert
Zusätzlich bestehen weitere drei Vorgehensziele:
• ein Projektfinanzierungsplan liegt bis zum 5. November 2007 vor
• das Projekt ist bis spätestens zum 30. April 2008 abgeschlossen
• die Projektbudget ist eingehalten
08-045 Kempf Danilo.pdf 3

1 PROJEKT UND PROJEKTZIELE
1.1.3 Eigene Position und Rolle im Projekt
Meine Linienposition ist die eines Softwareentwicklers bei der Telco-Soft GmbH.
Bezugnehmend auf dieses spezifische Projekt bin ich insbesondere in der Entwurfsphase
involviert und an der Entwicklung der Software-Architektur beteiligt.
Weiterhin stehe ich als Spezialist für Next Generation Networks den
Kollegen jederzeit beratend zur Verfügung.
Meine konkrete Rolle im Projekt ist die des Projektleiters. Dabei erfülle ich
planende, koordierende sowie überwachende Aufgaben.
Diese Aufgabenteilung erklärt meine Einordnung im Projektsteckbrief sowohl
als Projektleiter (80%) als auch als Entwickler (20%).
1.2 Zielbeschreibung und Zielhierarchie
1.2.1 Zieldefinition des Auftraggebers
Im Gespräch mit dem Auftraggeber wurden die expliziten Hauptziele des
Projekts ermittelt und festgehalten. Diese stellen die grundsätzlichen Anforderungen
des Auftraggebers dar, sind jedoch sehr grob gefaßt und reichen zur
konkreten Projektzieldefinition nicht aus.
Abstraktes Oberziel ist es, langfristig alle Nutzer der AFP NetStar-
Schnittstelle über die geschaffene Adapterlösung zur Nutzung der Telco-
Soft-Schnittstelle zu bewegen. Dieses Ziel nimmt zwar indirekt Einfluß auf
alle weiteren Projektziele und letztlich auf alle im Projektverlauf zu treffenden
Entscheidungen, ist aber dennoch weder Gegenstand des Projekts noch
dieses Transfernachweises.
Oberziel
O Es wird eine Adapterlösung geschaffen, durch die die AFP NetStar-
Schnittstelle in die Telco-Soft TelAPI-Schnittstelle integriert wird.
Ergebnisziele
E1 Im Rahmen des Projektes werden die Interna der NetStar-Schnittstelle
dokumentiert, um Grundlagen für weitere Pflege und Support zu schaffen.
E2 Die NetStar-Schnittstelle wird derart angepaßt, daß sie nicht selbst als
Netzzugangslösung dient, sondern die Telco-Soft-Schnittstelle nutzt.
E3 Die geschaffene Software muß das Kriterium ,,Carrier Grade” erfüllen,
muß also gleichermaßen stabil als auch performant funktionieren.
E4 Um Impulse zu setzen, ist die geschaffene Software bis zur CeBIT 2008
(Beginn 4. März 2008) in einem demonstrierbaren Status. Dies bedeutet
jedoch nicht, daß die Entwicklung bzw. Implementierung zu diesem
4 Danilo Kempf

ZIELBESCHREIBUNG UND ZIELHIERARCHIE 1.2
Zeitpunkt abgeschlossen sein muß oder das das Projekt zu diesem Zeitpunkt
beendet ist.
E5 Die ehemaligen Mitarbeiter der AFP GmbH werden in das Entwicklerteam
der Telco-Soft GmbH integriert.
Vorgehensziele
V1 Ein Projektfinanzierungsplan ist zu erstellen und spätestens 5. November
2007 vorgelegt.
V2 Das Projekt ist bis spätestens zum 30. April 2008 abgeschlossen.
V3 Das Projektbudget von e 250.000 wird eingehalten oder unterschritten.
1.2.2 Präzisierung und Operationalisierung
Die durch den Auftraggeber vorgegebenen Ziele sind abstrakt bzw. in Form
einer Aufgabenstellung formuliert und müssen, damit für das Projekt eine
konkrete Zieldefinition genannt werden kann, präzisiert und operationalisiert
werden.
O Ziel
E1 Ziel
E2 Ziel
Eine Adapterlösung ist implementiert, die für Applikationen die
AFP NetStar-Schnittstellen anbietet, intern aber auf der TelAPI-
Schnittstelle der Telco-Soft GmbH aufsetzt. Die Adapterlösung ist
für Kunden der Telco-Soft GmbH verfügbar.
Zielklassifizierung
Oberziel
Bemessungskriterium
Dieses Oberziel gilt als erreicht, wenn alle Ergebnisziele sowie alle
Vorgehensziele erreicht sind, wobei auftretende Zielkonflikte aufgelöst
sind.
Die AFP-Schnittstelle ist dokumentiert.
Zielklassifizierung
Ergebnisziel (Leistungsziel)
Bemessungskriterium
Bei Projektende wird dem Auftraggeber eine Schnittstellendokumentation
ausgehändigt, die dem bei der Telco-Soft GmbH intern
genutzten Dokumentationsstandard entspricht. Als Beleg gilt das
vom Auftraggeber unterzeichnete Abnahmeprotokoll.
Eine Adaptionssoftware von AFP- auf Telco-Soft-Schnittstelle ist
implementiert.
Zielklassifizierung
Ergebnisziel (Leistungsziel)
08-045 Kempf Danilo.pdf 5

1 PROJEKT UND PROJEKTZIELE
E3 Ziel
E4 Ziel
E5 Ziel
Bemessungskriterium
Bei Projektende ist der Quellstamm der Software im Versionskontrollsystem
der Telco-Soft GmbH eingepflegt und dem Auftraggeber
übergeben. Als Beleg gilt auch hier das unterzeichnete Abnahmeprotokoll.
Die Software erfüllt alle Qualitätskriterien, wie sie in der Telco-Softinternen
Qualitätsdefinition niedergelegt sind.
Zielklassifizierung
Ergebnisziel (Leistungsziel)
Bemessungskriterium
Das Qualitätssicherungs-Team der Telco-Soft GmbH gibt die Software
für Weitergabe an den Kunden frei. Es ist ein für den Komplexitätsgrad
der Software angemessenes Testprotokoll definiert. Bei
der Durchführung der Tests treten keine Defekte auf, deren Schweregrad
als kritisch oder hoch eingestuft wird.
Als Grundlage zur Bemessung der Qualität dient das hausinterne
Dokument Qualität und Testverfahren in der (aktuellen) Revision
vom 4. August 2006.
Eine demonstrierbare Version ist zur CeBIT 2008 verfügbar.
Zielklassifizierung
Ergebnisziel (Terminziel)
Bemessungskriterium
Bis vor Beginn der CeBIT 2008 (4. März 2008) ist eine erste Version
der Software verfügbar. Diese ist durch die Qualitätssicherung
geprüft und zumindest unter Aufsicht prinzipiell lauffähig.
Die ehemaligen Mitarbeiter der AFP GmbH sind in das Entwicklerteam
der Telco-Soft GmbH integriert.
Zielklassifizierung
Ergebnisziel (soziales Ziel)
Bemessungskriterium
Kompetenzbereiche der neuen Mitarbeiter sind erkannt, gegebenenfalls
übernehmen die neuen Mitarbeiter für ihr jeweiliges Fachgebiet
eine Spezialistenrolle bei Telco-Soft. Die Mitarbeiter sind in
die Firmenkultur der Telco-Soft GmbH eingegliedert, soziale Integration
ist erfolgt.
Zur Bemessung dieses Ziels wird zum Projektende ein Fragebogen
an die Projektmitarbeiter vergeben, auf dem zunächst in Skalenform
der Grad der Integration sowie das Konfliktpotential abzutragen
ist. Weiterhin enthält dieser Fragebogen Möglichkeiten
Wünsche und Anregungen in textueller Form zu äußern.
6 Danilo Kempf

V1 Ziel
V2 Ziel
V3 Ziel
ZIELBESCHREIBUNG UND ZIELHIERARCHIE 1.2
Letztlich kann dieses Ziel erst als erreicht gelten, wenn sich herausstellt,
daß die neuen Mitarbeiter über längere Zeit (mir erscheinen
als Grundlage hier mindestens drei Jahre günstig) im Unternehmen
verbleiben.
Ein Projektfinanzierungsplan liegt bis spätestens zum 5. November
2007 vor.
Zielklassifizierung
Vorgehensiziel (Terminziel)
Bemessungskriterium
Ein Finanzierungsplan ist bis zum 5. November 2007 erstellt und
dem Auftraggeber vorgelegt. Dieser Finanzierungsplan wird durch
den Auftraggeber genehmigt.
Das Projekt ist bis spätestens zum 30. April 2008 abgeschlossen.
Zielklassifizierung
Vorgehensziel (Terminziel)
Bemessungskriterium
Die Abnahme ist am 30. April 2008 oder früher erfolgt. Als Kriterium
dient das Datum des unterzeichneten Abnahmeprotokolls.
Das Projektbudget ist eingehalten.
Zielklassifizierung
Vorgehensziel (Finanzziel)
Bemessungskriterium
Bei Projektende ist das Projektbudget in Höhe von e 250.000 exakt
eingehalten oder unterschritten.
1.2.3 Zielhierarchie
Hierarchisch lassen sich die genannten Ziele in Ergebnisziele, die die Qualität
des Produktes beschreiben, sowie in Vorgehensziele, die die Qualität
des Projektmanagements beschreiben, gliedern. Beide Gruppen gliedern sich
wiederum in Untergruppen, um granularere Klassifizierung der Ziele zu
ermöglichen. Grafisch spiegelt sich dies in der Zielhierarchie in Abbildung 1.1
bzw. in der alternativen Darstellung in Abbildung 1.2 wieder.
08-045 Kempf Danilo.pdf 7

1 PROJEKT UND PROJEKTZIELE
Leistung
Termin
sozial
Finanz
O Adapterlösung für Kunden verfügbar
E Ergebnisziele
E1 Dokumentation
E2 Implementierung
E3 Qualität
E4 CeBIT 2008
E5 Integration
V Vorgehensziele
V1 Finanzierungsplan
V2 Projektabschluß
V3 Budget
Die Zielbezeichnungen sind in der Abbildung verkürzt wiedergegeben.
Abbildung 1.1 Zielhierarchie
Hierarchieebene zugeordnete Ziele
Oberziel O
Ergebnisziele
Leistungsziele E1 E2 E3
Terminziele E4
soziale Ziele E5
Vorgehensziele
Terminziele V1 V2
Finanzziele V3
Abbildung 1.2 Zielhierarchie (alternative Darstellung)
8 Danilo Kempf

1.3 Zielbeziehungen und Zielkonflikte
ZIELBEZIEHUNGEN UND ZIELKONFLIKTE 1.3
Nicht alle Projektziele sind in jedem Falle miteinander vereinbar. Somit ist als
nächster Schritt eine Zielbeziehungsmatrix zu erstellen, die untersucht, wie
Projektziele einander beeinflussen. Der Grad der Beeinflussung wird hier auf
einer fünfgeteilten Skala, die wie folgt definiert ist, angegeben.
ID Zwischen zwei Zielen herrscht eine Identitätsbeziehung – die Ziele sind
also identisch.
K+ Zwei Ziele sind zueinander komplementär. Das Erreichen des einen
begünstigt das Erreichen des anderen Zieles.
N Zwei Ziele verhalten sich zueinander neutral und üben keinen Einfluß
aufeinander aus.
K- Zwischen zwei Zielen besteht eine Konkurrenzbeziehung. Erreichen eines
Zieles erschwert das Erreichen des zweiten Zieles.
AN Zwischen zwei Zielen herrscht Antinomie. Wird ein Ziel erreicht, ist das
Erreichen des anderen Zieles unmöglich – beide Ziele schließen sich also
gegenseitig aus.
Die definierten Projektziele verhalten sich wie in der in Abbildung 1.3 dargestellten
Kreuztabelle dargestellt zueinander.
E1 E2 E3 E4 E5 V1 V2
V3 N N N K- N K+ N
V2 N N N N N N
V1 N N N N N
E5 K+ K- N N
E4 AN K+ N
E3 K+ K+
E2 K+
Abbildung 1.3 Zielbeziehungen
Aus der Abbildung werden drei Zielkonflikte deutlich. Zielantinomien machen
unter Umständen den Projektabschluß unter Erreichung aller Ziele
unmöglich, gegebenenfalls muß dann auf das Erreichen mindestens eines der
Ziele verzichtet werden. Zielkonkurrenzen erschweren das Erreichen der konkurrierenden
Ziele, machen es jedoch nicht unmöglich.
08-045 Kempf Danilo.pdf 9

1 PROJEKT UND PROJEKTZIELE
Zielantinomie zwischen Ziel E1 und E4
Ziele
E1 Die AFP-Schnittstelle ist dokumentiert.
E4 Eine demonstrierbare Version ist zur CeBIT 2008 verfügbar.
Zielbeziehung
Zielantinomie ( AN )
Konflikt
Das Erstellen einer vollständigen Dokumentation der Interna der AFP-
Schnittstelle bindet die dafür zuständigen Entwickler, was sich u.U. negativ
auf den Demonstrationstermin zur CeBIT auswirken könnte.
Lösung
Die Dokumentation der Interna ist für die Entwicklung einer darauf
aufbauenden Softwarelösung zwingend erforderlich, hat also
grundsätzlich Vorrang vor dem CeBIT-Termin. Ziel E1 hat gegenüber
Ziel E2 also Priorität.
Generell ist allerdings genügend zeitlicher Puffer vorhanden, so daß
dennoch vom Erreichen beider Ziele auszugehen ist. Dementsprechend
äußert sich dieser Zielkonflikt nicht zwangsläufig in einer Antinomiebeziehung,
sondern könnte (optimistischer) auch als Zielkonkurrenz (also
K- ) betrachtet werden.
Zielkonkurrenz zwischen Ziel E2 und E5
Ziele
E2 Eine Adaptionssoftware von AFP- auf Telco-Soft-Schnittstelle ist
implementiert.
E5 Die ehemaligen Mitarbeiter der AFP GmbH sind in das Entwicklerteam
der Telco-Soft GmbH integriert.
Zielbeziehung
Zielkonkurrenz ( K- )
Konflikt
Das Zerlegen der AFP-Schnittstelle und die Integration von Restkomponenten
in die Telco-Soft-Schnittstelle birgt großes Konfliktpotential zur
Team-Integration. Beide Produkte waren vormals konkurrierend und
technisch durchaus gleichwertig. Für keinen der beteiligten Entwickler
wird es angenehm sein, mit und an dem jeweiligen Fremdprodukt intensiv
arbeiten zu müssen.
Lösung
Dies ist kein wirklich auflösbarer Zielkonflikt. Im Zuge des Projektverlaufs
wird versucht, im Rahmen der Stakeholderkommunikation und
im Rahmen der Teambildungsmaßnahmen abschwächend auf die negativen
Effekte dieses Zielkonfliktes einzuwirken.
10 Danilo Kempf

Zielkonkurrenz zwischen Ziel E4 und V3
Ziele
ZIELBEZIEHUNGEN UND ZIELKONFLIKTE 1.3
E2 Eine demonstrierbare Version ist zur CeBIT 2008 verfügbar.
V3 Das Projektbudget ist eingehalten.
Zielbeziehung
Zielkonkurrenz ( K- )
Konflikt
Das Erstellen einer Demonstrationsversion für die CeBIT ist durchaus
kostenintensiv und steht daher einer Minimierung der Projektkosten
entgegen. Die Software muß zum Termin in einem akzeptablen Status,
außerhalb der Entwicklungsumgebung lauffähig, getestet und zumindest
eingeschränkt abgenommen sein.
Lösung
Grundsätzlich hat hier der CeBIT-Termin höhere Priorität als die absolute
Kostenminimierung. Während das Budget zwar eingehalten sein will,
muß der Projektfinanzierungsplan die durch die CeBIT-Version verursachten
Kosten enthalten und auffangen.
08-045 Kempf Danilo.pdf 11

Projektumfeld und Stakeholder 2
2.1 Projektumfeld
Zu – oder idealerweise bereits vor – Projektbeginn empfiehlt es sich, eine detaillierte
Analyse des Projektumfeldes vorzunehmen. Bei langlaufenden Projekten
ist diese Umfeldanalyse auch regelmaßig neu zu vollziehen, um sich
ändernde Umfeldaspekte objektiv einordnen zu können und sichtbar zu machen.
2.1.1 Umfeldfaktoren
Erster Schritt einer Umfeldanalyse ist das Identifizieren der projektrelevanten
Umfeldfaktoren. Für das vorliegende Projekt sind dies die im Folgenden
wiedergegebenen:
1 Umfeldfaktor
Auftraggeber
Beziehung zum Projekt
direkt, intern, persönlich
Personen
Michael Sieber und Burkhard Römer
Anmerkungen
Auftraggeber sind Herr Michael Sieber und Herr Burkhard Römer,
Geschäftsführer der Telco-Soft GmbH. In dieser Position haben beide
ein großes Interesse am Projekterfolg und stellen Machtpromotoren
dar.
2 Umfeldfaktor
Projektleiter
Beziehung zum Projekt
direkt, intern, persönlich
Personen
Danilo Kempf
Anmerkungen
Grundsätzlich ist es unüblich, den Projektleiter (also quasi sich
selbst) als Umfeldfaktor aufzuzeichnen. Ich halte dies in diesem
08-045 Kempf Danilo.pdf 13

2 PROJEKTUMFELD UND STAKEHOLDER
Projekt der sozialen Problematik wegen für durchaus nicht unwichtig.
3 Umfeldfaktor
Softwareentwickler (Telco-Soft)
Beziehung zum Projekt
direkt, intern, persönlich
Personen
Martin Riedel und Thomas Ernemann
Anmerkungen
Herr Martin Riedel und Herr Thomas Ernemann sind Softwareentwickler
bei der Telco-Soft GmbH und maßgeblich an der Entwicklung
der Telefonieschnittstelle beteiligt. Als solches besteht auch
hier erhebliches Interesse am Projekterfolg.
Martin Riedel ist auch Fachpromotor für dieses Projekt.
4 Umfeldfaktor
Softwareentwickler (ehemals AFP GmbH)
Beziehung zum Projekt
direkt, intern, persönlich
Personen
Michael Walm und Sören Schneider
Anmerkungen
Michael Walm und Sören Schneider waren bei der AFP GmbH in
erheblichem Umfang an der Entwicklung der NetStar-Schnittstelle
beteiligt, die ein Konkurrenzprodukt zur TelAPI-Schnittstelle der
Telco-Soft GmbH darstellte. Beide sind nun bei der Telco-Soft
GmbH beschäftigt und am Projekt beteiligt. Hier besteht also ein
erhöhtes Konfliktpotential.
Siehe auch 3 Risikoanalyse 〈S. 23〉.
5 Umfeldfaktor
weitere Projektmitarbeiter
Beziehung zum Projekt
direkt, intern, persönlich
Personen
Torben Rahlich, Jens Wippel, Lothar Karlson und Jürgen Kurzmann
Anmerkungen
Die weiteren Projektmitarbeiter (technische Unterstützung, Qualitätssicherung
und Dokumentation) stehen dem Projekt neutral
bzw. ambivalent gegenüber.
6 Umfeldfaktor
nicht am Projekt beteiligte Mitarbeiter der Telco-Soft GmbH
14 Danilo Kempf

Beziehung zum Projekt
indirekt, intern, persönlich
PROJEKTUMFELD 2.1
Anmerkungen
Die weiteren Mitarbeiter der Telco-Soft GmbH sind nicht am Projekt
beteiligt, üben durch Linienfunktion bzw. durch die Beteiligung
an anderen Projekten jedoch zumindest indirekt Einfluß auf
dieses Projekt aus.
7 Umfeldfaktor
Imaginary Networks AG (Kunde)
Beziehung zum Projekt
direkt, extern, persönlich
Anmerkungen
Der Kunde hat eine grundsätzlich positive Beziehung zum Projekt
und Interesse am Projektgelingen. Wenngleich die Einstellung zum
Projekt rundheraus positiv ist, ist es dennoch Fakt, daß sich die
Imaginary Networks AG ursprünglich für die AFP- und gegen die
Telco-Soft-Schnittstelle entschieden hatte. Seit Insolvenz der AFP
GmbH ist nun an dieser Schnittstelle keine weitere Arbeit geleistet
worden und ihr Quelltext ist in den Einflußbereich des ehemaligen
technischen Konkurrenten gelangt. Dadurch besteht natürlich seitens
des Kunden eine erheblicher Unsicherheitsfaktor.
8 Umfeldfaktor
weitere Kunden der erloschenen AFP GmbH
Beziehung zum Projekt
indirekt, extern, persönlich
Anmerkungen
Weitere Kunden der AFP GmbH, also weitere Nutzer der NetStar-
Schnittstelle, können gegebenenfalls auch von der im Projekt zu
schaffenden Adapterlösung profitieren.
9 Umfeldfaktor
interne Vorgaben
Beziehung zum Projekt
direkt, intern, sachlich
Anmerkungen
Interne Vorgaben (also definierte Entwicklungsprozesse, Qualitätsvorgaben)
wirken sich auf den Projektverlauf aus.
10 Umfeldfaktor
externe Vorgaben
Beziehung zum Projekt
direkt, extern, sachlich
Anmerkungen
Externe Vorgaben, technische Spezifikationen, Standards und Normen
schränken die Möglichkeiten zur Projektabwicklung ein.
08-045 Kempf Danilo.pdf 15

2 PROJEKTUMFELD UND STAKEHOLDER
11 Umfeldfaktor
Linienaufgaben
Beziehung zum Projekt
indirekt, intern, sachlich
Anmerkungen
Die am Projekt teilnehmenden Mitarbeiter nehmen weiterhin eingeschränkt
ihre Linienaufgaben war. Linienaufgaben mit höherer
Priorität können den Projektablauf negativ beeinflussen.
12 Umfeldfaktor
weitere Projekte der Telco-Soft GmbH
Beziehung zum Projekt
indirekt, intern, sachlich
Anmerkungen
Zeitgleich zu diesem Projekt finden bei der Telco-Soft GmbH gegebenenfalls
weitere Projekte statt, die möglicherweise zu Ressourcenkonflikten
führen könnten.
13 Umfeldfaktor
Konkursmasse der AFP GmbH
Beziehung zum Projekt
direkt, extern, sachlich
Anmerkungen
Die Telco-Soft GmbH hat Teile der Konkursmasse der AFP GmbH
erworben, insbesondere einige Software-Quelltexte. Ohne diese
wäre eine Entwicklung einer solchen Adapterlösung nicht möglich
und das Projekt könnte als solches nicht stattfinden.
2.1.2 Grafische Darstellung des Projektumfeldes
Aus der strukturierten Umfeldbetrachtung im vorangegangenen Abschnitt
ergibt sich eine grafische Darstellung der genannten Umfeldfaktoren. Diese
ist in Abbildung 2.1 wiedergegeben.
Im Zentrum der Grafik – also am Schnittpunkt der beiden Achsen – befindet
sich das Projekt selbst. Um das Projekt herum zeigt der innere Kreis alle
Umfeldfaktoren, die sich direkt auf das Projekt auswirken, der äußere Kreis
hingegen alle Umfeldfaktoren, die sich indirekt auf das Projekt auswirken.
Durch die Achsen wird die Grafik in vier Quadranten gegliedert. Die oberen
beiden Quadranten zeigen alle internen, also am Projekt beteiligten, Umfeldfaktoren,
die beiden unteren die nicht direkt am Projekt beteiligten, also
externen Umfeldfaktoren. Analog teilt die vertikale Achse zwischen sachlichem
Umfeld auf der linken und persönlichem Umfeld bzw. Stakeholdern auf der rechten
Seite.
Die Positionierung der Umfeldfaktoren gibt grob die Nähe zum Projekt
wieder.
16 Danilo Kempf

intern
extern indirekt direkt
2.2 Stakeholder
11
12
9
13
10
2 3
4
sachliches Umfeld Stakeholder
Abbildung 2.1 Grafische Darstellung des Projektumfelds
1
7
5
STAKEHOLDER 2.2
Im vorangeganenen Abschnitt wurde eine strukturierte Betrachtung des Projektumfeldes
vorgenommen. Aus dieser gingen natürliche bzw. juristische
Personen hervor, die direkt oder indirekt das Projekt beeinflussen. Diese Personen
werden als Stakeholder bezeichnet.
Stakeholder lassen sich, basierend auf dem jeweiligen Grad der Betroffenheit,
im Wesentlichen in drei Gruppen gliedern:
+++ Betroffene Stakeholder werden vom Projekt in hohem Maße positiv oder
negativ beeinflußt. Sie selbst wirken ggf. ebenfalls stark auf das Projekt
ein.
++ Beteiligte Stakeholder nehmen an der Projektdurchführung teil und beeinflussen
das Projekt damit, werden aber selbst durch das Projekt nicht
beeinflußt.
+ Interessierte Stakeholder zeigen Interesse am Projekt, nehmen aber we-
08-045 Kempf Danilo.pdf 17
6
8

2 PROJEKTUMFELD UND STAKEHOLDER
der am Projekt teil, noch üben sie nenneswerten Einfluß aus oder werden
durch das Projekt beeinflußt.
Jedem Stakeholder lassen sich – neben der Gruppe, der er angehört – mehrere
Werte zuordnen, die zur Analyse der Position zum Projekt hilfreich sind.
Insbesondere sind folgende Werte interessant:
Konfliktpotential
Das Konfliktpotential wird hier auf einer Skala von 0 (kein Konfliktpotential)
bis 10 (außerordentlich hohes Konfliktpotential) bemessen und
gibt an, mit welcher Wahrscheinlichkeit der jeweilige Stakeholder mit
dem Projektablauf in Konflikt gerät.
Machtpotential
Das Machtpotential wird ebenfalls auf einer Skala von 0 (kein Machtpotential)
bis 10 (außerordentlich hohes Machtpotential) bemessen und
gibt an, in welchem Umfang ein Stakeholder Einfluß auf das Projekt
nehmen kann.
Greift man nun die Stakeholder die aus der Analyse des Projektumfelds ersichtlich
geworden sind auf und ordnet ihnen qualifiziert die genannten Werte
zu, ergibt sich folgendes Bild:
Nr Stakeholder Betroffen- Konflikt- Machtheit
potential potential
1a Michael Sieber
(Auftraggeber)
1b Burkhard Römer
(Auftraggeber)
2 Danilo Kempf
(Projektleiter)
3a Martin Riedel
(Entwickler)
3b Thomas Ernemann
(Entwickler)
4a Michael Walm
(Entwickler)
4b Sören Schneider
(Entwickler)
5 weitere
Projektmitarbeiter
6 weitere Mitarbeiter der
Telco-Soft GmbH
7 Imaginary Networks AG
(Kunde)
+++ 2 10
+++ 1 10
+++ 1 8
+++ 1 7
++ 2 7
+++ 8 7
+++ 7 7
++ 3 4
+ 1 3
+++ 5 10
18 Danilo Kempf

STAKEHOLDERPORTFOLIO UND STAKEHOLDERSTEUERUNG 2.3
8 weitere Kunden der AFP
GmbH
+ 1 1
2.3 Stakeholderportfolio und Stakeholdersteuerung
Macht- bzw. Konfliktpotential, die im vorangegangenen Abschnitt tabellarisch
aufgezeichnet worden sind, lassen sich in einem Koordinatensystem abtragen,
um so grafisch die projektrelevanten Ziel- und Interessenslagen der
einzelnen Stakeholder zu verdeutlichen. Diese grafische Repräsentation wird
als Stakeholderportfolio bezeichnet und ist in Abbildung 2.2 dargestellt.
Konfliktpotential
10
8
6
4
2
8
6
5
0
0 2 4 6 8 10
Macht/Einfluß
Die Pfeile geben die intendierte Wirkrichtung der steuernden Maßnahmen wieder.
Abbildung 2.2 Stakeholderportfolio und Stakeholdersteuerung
08-045 Kempf Danilo.pdf 19
4a
4b
3b
3a
2
7
1a
1b

2 PROJEKTUMFELD UND STAKEHOLDER
Im Diagramm ist leicht zu erkennen, daß erhöhtes Konfliktpotential mit
den ehemaligen Mitarbeitern der AFP GmbH ( 4a und 4b ) besteht – gleichzeitig
können diese relativ umfangreich Einfluß auf das Projekt nehmen. Gleiches
gilt für den Kunden ( 7 ).
Während die anderen Stakeholder dem Projekt prinzipiell ambivalent bis
positiv gegenüber stehen und keiner ausdrücklichen aktiven Steuerung – außer
gegebenenfalls der Bestärkung der jeweiligen Positiva – bedürfen, muß
also auf die drei genannten Stakeholder aktiv eingewirkt werden.
Das Macht- bzw. Einflußpotential wird sich im Rahmen des Projektes nicht
ändern lassen – es kann lediglich auf das Konfliktpotential senkend Einfluß
genommen werden. Die intendierte Richtung dieser Einflußnahme ist im Stakeholderportfolio
in Form der Pfeile wiedergegeben.
Neben den Teambildungsmaßnahmen (9.1 Teamarbeit (Teambildung und
Konflikte) 〈S. 81〉) manifestiert sich die Stakeholdersteuerung im wesentlichen
in Form gesteuerter Kommunikationsmaßnahmen. Diese können in bezüglich
der Projektrelevanz absteigender Ordnung der Kommunikationsmatrix in Abbildung
2.3 entnommen werden.
In der Kommunikationsmatrix, gibt die Spalte Weg den gewählten Kommunikationsweg
wieder. Dabei indiziert P persönliche und S schriftliche
Kommunikation. PS stellt eine Kombination aus sowohl persönlicher
als auch schriftlicher Kommunikation dar.
Das Kommunikationsklima beziehungsweise die Stimmung wird auf folgender
Skala angegeben:
negativ neutral positiv
-- - 0 + ++
Grundsätzlich wird für alle Stakeholder eine eher partizipative Kommunikationsstrategie
gewählt. Da sowohl vom Kunden als auch von projektexternen
Stakeholdern keine Partizipation zu erwarten ist, dürfte sich hier in der
Praxis eher eine diskursive Kommunikation ergeben.
Aus der stichpunktartigen Beschreibung der zu wählenden Kommunikationsmaßnahmen
wird deutlich, daß für dieses Projekt im Wesentlichen bereits
bestehende Kommunikationsstrukturen genutzt werden können – letztlich
handelt es sich bei diesem Projekt nicht um das Erste oder das Einzige
seiner Art bei der Telco-Soft GmbH.
Kommunikationsmittel, die bei der Telco-Soft GmbH auch nichtprojektspezifisch
genutzt werden sind insbesondere:
wöchentliche Lagebesprechungen
In der Vergangenheit hat es sich als sinnvoll erwiesen, in einem wenig
formalen Umfeld wöchentliche projektspefische Lagebesprechun-
20 Danilo Kempf

STAKEHOLDERPORTFOLIO UND STAKEHOLDERSTEUERUNG 2.3
Nr Stakeholder Weg Klima Häufigkeit Maßnahme
4 Softwareentwickler
PS - sehr oft Gespräche, ,,Türrahmen-
Austausch”, besonderes
Einbeziehen in fachliche
Entscheidungen, Projektkalender,
Statusupdates alle
drei Tage
7 Kunde S 0 oft schriftliches wöchentliches
Informationsupdate
3 Software- PS ++ oft Gespräche, Projektkalenentwicklerder,
Statusupdates alle drei
Tage
5 Projektmitarbeiter
PS + oft . . . dito. . .
1 Auftrag- PS + sehr oft tägliches Update auf
geber
kurzem Dienstweg, regelmäßigeProjektbesprechung,
schriftliche Berichte
6 weitere PS 0 selten sporadisch Projektupdates
Mitarbeiter
im Intranet/Wiki
Abbildung 2.3 Kommunikationsmatrix
gen abzuhalten. An diesen können auch projektfremde interessierte Mitarbeiter
passiv, aber auch konstruktiv aktiv teilnehmen – gleichermaßen
ist es allen Projektmitarbeitern gestattet, diesen Besprechungen jederzeit,
und ohne sich dafür rechtfertigen zu müssen, fernzubleiben.
Dieser Freiwilligkeitsfaktor führt letzten Endes zu einem äußerst angenehmen
Gesprächsklima, in dem durchaus auch negative Faktoren
wie technische oder terminliche Schwierigkeiten angstfrei angesprochen
werden können.
öffentlicher Projektkalender
Gleichzeitig wird für alle Projekte, die von oder unter Beteiligung der
Telco-Soft GmbH durchgeführt werden ein für alle Mitarbeiter einsehbarer
Projektkalender genutzt.
Intranet/Wiki
Alle Projektinformationen – insbesondere technischer Natur – werden
in einem zentralen Intranet-System, das mit einer Wiki-Lösung verzahnt
ist, gepflegt. Hier sind die umfangreichsten Informationen jedoch
nur für am Projekt tatsächlich teilnehmende Mitarbeiter verfügbar. Sporadisch
werden destillierte Informationen für alle anderen Mitarbeiter
08-045 Kempf Danilo.pdf 21

2 PROJEKTUMFELD UND STAKEHOLDER
zugänglich gemacht. Dieses System wird auch von einigen Kunden im
Rahmen von Projekten zur Kommunikation mit der Telco-Soft GmbH
genutzt. Im vorliegenden Projekt ist dies jedoch nicht der Fall.
Hervorzuheben sind insbesondere die Kommunikationsmaßnahmen mit
den Stakeholder Nr. 4, also den ehemaligen Mitarbeitern der AFP GmbH.
Diese sind erst seit relativ kurzer Zeit bei der Telco-Soft GmbH beschäftigt
und somit sozial nicht vollkommen in das Team integriert. Um hier Spannungen,
die zwangsläufig durch das Zerlegen der NetStar-Schnittstelle und
Integrieren der technisch anspruchsloseren Teile dieser Schnittstelle in die
Telco-Soft-Software-Architektur entstehen entgegenzuwirken, sind insbesondere
mit diesen Mitarbeiter umfangreiche Kommunikationsmaßnahmen erforderlich.
Die Entwickler der Telco-Soft GmbH wurden angehalten, die neuen
Mitarbeiter insbesondere in den Entwicklungsprozeß der Adapterlösung
zu integrieren und in besonderem Umfang technische Fragen gemeinsam zu
erörtern und gemeinsam als Team Lösungen zu erarbeiten.
Für weitere Informationen sei auf den Abschnitt 9.1 Teamarbeit (Teambildung
und Konflikte) 〈S. 81〉 verwiesen.
22 Danilo Kempf

Risikoanalyse 3
Mit der Risikoanalyse werden Risiken, also alle Vorgänge und Ereignisse, die
das Projekt negativ beeinflussen können, einer systematischen Bewertung unterzogen.
Anhand dieser Bewertung können dann geeignete Maßnahmen getroffen
werden, um den Risiken bzw. deren Auswirkungen gezielt entgegenzuwirken.
Wie alle Planungsinstrumente ist auch die Risikoanalyse kein isoliert stattfindender
Vorgang. Vielmehr wird während des gesamten Projektverlaufs die
Risikoanalyse kontinuierlich vollzogen und neuen Gegebenheiten angepaßt.
3.1 Erfassung, Klassifizierung und Beschreibung der Risiken
Erster Schritt der Risikoanalyse ist das Ermitteln der das Projekt bedrohenden
Risiken. Ein Weg dazu ist in Abbildung 3.1 grafisch dargestellt.
Ressourcen
Risiken
Überlastung
Team
Laborkapazität
politisch
technisch
Akzeptanz
ehem.
Mitarbeiter
AFP
terminlich CeBIT 2008
Qualität
Umsetzbarkeit
Projektabschluß
Abbildung 3.1 Mindmap zur Risikoermittlung
08-045 Kempf Danilo.pdf 23

3 RISIKOANALYSE
Ausformuliert ergeben sich also die folgenden Projektrisiken:
1 Risiko
ehemalige Mitarbeiter der AFP GmbH
Kategorisierung
politisches bzw. soziales Risiko
Beschreibung
Dadurch bedingt, daß die ehemaligen Mitarbeiter der AFP GmbH
jetzt bei der Telco-Soft GmbH ihr eigenes ehemaliges Produkt zerlegen
und in das ehemalige Konkurrenzprodukt der Telco-Soft
GmbH aufgehen lassen sollen, stellt sich das Risiko, daß technische
Informationen nur sehr zögerlich bzw. ungern weitergegeben werden
und quasi stiller Widerstand stattfindet. Dies wiederum stellt
sowohl den technischen als auch den zeitlichen Projekterfolg und
in letzter Instanz auch die Teambildung (die ja ebenfalls Projektziel
E5 ist) in Frage.
2 Risiko
mangelnde Akzeptanz der Lösung
Kategorisierung
politisches Risiko
Beschreibung
Ein Integrieren von Einzelkomponenten der NetStar-Schnittstelle
in die TelAPI der Telco-Soft GmbH hat einen gewissen Patchwork-
Charakter. Wenngleich dieser Lösungsweg mit dem Kunden abgestimmt
ist, besteht dennoch das Risiko, daß eine solche Lösung
nicht auf die nötige Akzeptanz stößt und letztlich – auch durchaus
nach dem Projektende – vom Kunden abgelehnt wird.
3a Risiko
CeBIT-Termin nicht haltbar
Kategorisierung
Terminrisiko
Beschreibung
Die unbekannte technische Basis erschwert vorab Zeitabschätzungen.
Somit besteht das Risiko, daß es nicht Möglich
ist, rechtzeitig zur CeBIT 2008 eine lauffähige Demonstrationsversion
zu erstellen.
3b Risiko
Projektabschlußtermin nicht haltbar
Kategorisierung
Terminrisiko
Beschreibung
Analog zu 3a ist auch hier durch die schwere Abschätzbarkeit
des Zeitbedarfs ein terminliches Risiko bezgüglich des Projektabschlußtermins
erkennbar.
24 Danilo Kempf

ERFASSUNG, KLASSIFIZIERUNG UND BESCHREIBUNG DER RISIKEN 3.1
4 Risiko
Umsetzbarkeit nicht sichergestellt
Kategorisierung
technisches Risiko
Beschreibung
Es ist nicht sichergestellt, daß eine Adapterlösung, wie sie im vorliegenden
Projekt implementiert werden soll technisch realisierbar
ist. Möglicherweise unterscheiden sich die Interna der AFP
NetStar-Schnittstelle zu stark von denen der Telco-Soft TelAPI-
Schnittstelle und machen damit die Realisierung unmöglich.
5 Risiko
Qualität der erstellten Lösung nicht ausreichend
Kategorisierung
technisches Risiko
Beschreibung
Durch den Charakter des Lösungsansatzes und durch die unbekannte
technische Basis bedingt, besteht ein erhöhtes Risiko, daß
sich in der erstellten Lösung Qualitätsprobleme manifestieren, wie
beispielsweise Instabilität oder Performance-Schwierigkeiten.
6 Risiko
Überlastung des Projektteams
Kategorisierung
Ressourcenrisiko
Beschreibung
Parallel zu diesem Projekt bestehen bei der Telco-Soft GmbH weitere
Projekte, ebenso werden von den Projektmitarbeitern weiterhin
Linienaufgaben wahrgenommen. Durch die Wahl der Projektorganisation
(4 Projektorganisation 〈S. 33〉) bedingt besteht das Risiko,
daß kritische Mitarbeiter ihre Projektaufgaben nicht jederzeit
in vollem Umfange wahrnehmen können bzw. nicht angemessen
von ihren Linienaufgaben freigehalten werden.
7 Risiko
Überlastung der Laborkapazität
Kategorisierung
Ressourcenrisiko
Beschreibung
Für die Entwicklung der Adapterlösung ist es nötig, zunächst
Kenntnis über die Software der Imaginary Networks AG als auch
über die NetStar-Schnittstelle der AFP GmbH zu erlangen. Dazu
sind umfangreiche Tests und Probeläufe nötig. Weiterhin sind
durch die ungewöhnliche Aufgabe enorm viele Tests zu vollziehen,
um das Funktionieren der Lösung sicherzustellen. Diese Aufgaben
08-045 Kempf Danilo.pdf 25

3 RISIKOANALYSE
binden sehr viele technische Ressourcen im Testlabor, die zeitgleich
eventuell bereits von anderen Projekten gebunden sind, was den
Projektablauf gefährden könnte.
3.2 Bewertung der Risiken
Nachdem – idealerweise alle – Projektrisiken identifiziert worden sind,
müssen diese objektiv bewertbar gemacht werden. Dazu wollen im Folgenden
drei Kriterien dienen:
Eintrittswahrscheinlichkeit
Es wird für jedes Risiko möglichst objektiv dessen Eintrittswahrscheinlichkeit
ermittelt. Beträgt diese 100%, handelt es sich es sich um ein unumstößliches
Problem, beträgt sie 0% handelt es sich nicht um ein Projektrisiko.
Schadenswert
Jedem Projektrisiko wird der sogenannte Schadenswert beigemessen.
Dieser sagt aus, welchen – meist monetären – Schaden das Risiko im
Falle seines Eintretens herbeiführt.
Risikowert
Als Kennzahl höherer Ordnung ergibt sich der Risikowert aus dem Produkt
von Eintrittswahrscheinlichkeit und Schadenswert. Mittels dieser
Maßzahl lassen sich Risiken zunächst recht gut zueinander in Relation
setzen, weiterhin gibt sie Auskunft über die tatsächlichen einem Risiko
zuzuordnenden Kosten, gleich, ob das Risiko eintritt oder nicht.
Theoretisch sind hier noch eine Vielzahl weiterer Maßzahlen denkbar, beispielsweise
subjektive, fachbezogene oder schlicht nicht monetär darstellbare
Faktoren. Im vorliegenden Projekt scheinen die Eintrittswahrscheinlichkeit
sowie der Schadenswert und der aus ihnen berechenbare Risikowert jedoch
hinreichend.
Im vorliegenden Projekt handelt es sich um ein Entwicklungsprojekt. Prinzipiell
tragen Forschungs- und Entwicklungsprojekte einen leichten Unsicherheitsfaktor
in sich, da der Projektausgang bedingt durch inhaltliche
Unwägbarkeiten zumindest in geringem Maße ungewiß ist. Im schlimmsten
Falle führt das Eintreten eines Projektrisikos zum Abbruch des Projektes, da
Kernziele nicht mehr erreichbar sind.
Mit dem Fehlschlagen eines Entwicklungsprojektes muß meines Erachtens
also eher gerechnet werden, als mit dem Fehlschlagen eines Investitionsoder
eines Organisationsprojektes. Wenn nun aber – auch in planerischer Hinsicht
– durchaus mit einem Fehlschlagen des Projektes zu rechnen ist, fällt es
schwer, für die zu veranschlagenden Schadenswerte eine monetäre Bemessungsgrundlage
zu finden, die über das Maximum der reinen Projektkosten
hinausgeht.
26 Danilo Kempf

BEWERTUNG DER RISIKEN 3.2
Konkret kann meines Erachtens aus innerprojektlicher Sicht der
höchstmögliche Schadenswert 100% der maximal veranschlagten Projektkosten
betragen.
Aus außerprojektlicher Sicht mag dies nicht zutreffen. Scheitert in einem
Programm ein Entwicklungsprojekt mit Schlüsselfunktion kann dadurch freilich
ein großer, die Projektkosten weit übersteigender Schaden entstehen.
Ebenso entsteht durch ein Scheitern des Projekts natürlich ein entgangener
Gewinn. In Absprache mit dem Auftraggeber, der Gewinnerwartungen auch
nicht im Rahmen dieses Transfernachweisen veröffentlicht wissen möchte,
möchte ich aber hier von einer monetären Bemessung der Schadenswerte absehen
und trage diese stattdessen auf einer abstrakten Skala im Bereich von 0
bis 100 ab.
Nr Eintritts- Schadens- Risiko- Risiko
wahrsch. wert wert
1 70% 70 49 ehem. Mitarbeiter AFP GmbH
2 30% 80 24 mangelnde Akzeptanz
3a 40% 40 16 CeBIT-Termin nicht haltbar
3b 20% 60 12 Projektabschlußtermin nicht
haltbar
4 40% 90 36 Umsetzbarkeit nicht sichergestellt
5 25% 75 19 Qualität nicht ausreichend
6 40% 60 24 Überlastung des Projektteams
7 40% 70 28 Überlastung der Laborkapazität
Diese Risikobewertung ist grafisch in Abbildung 3.2 dargestellt.
In der Grafik ist gut erkennbar, daß die vertikale Achse nur gegen ihre
Grenzwerte tendiert, sie jedoch nicht umschließt. Dies gibt die Tatsache wieder,
daß Risiken mit einer Eintrittswahrscheinlichkeit von 0% eben keine Risiken
sind und das Risiken mit einer Eintrittswahrscheinlichkeit von 100%
stattdessen unumstößliche Fakten darstellen, die nicht im Rahmen einer Risikoanalyse
diskutiert werden wollen.
Die Grafik enthält zwei weitere auffällige Punkte: zunächst habe ich sie
in drei farblich jeweils unterschiedlich unterlegte Bereiche gegliedert, die die
Tragweite bzw. den Risikowert der einzelnen Projektrisiken verdeutlichen.
Der weiße Bereich nimmt die Projektrisiken geringer, der hellrote Bereich Risiken
mittlerer und der dunkelrote Bereich Projektrisiken hoher Tragweite in
sich auf.
Wie – und ob – eine solche Gliederung in Tragweitenklassen erfolgt, bleibt
letztlich der Projektleitung bzw. dem Auftraggeber selbst überlassen, feste
08-045 Kempf Danilo.pdf 27

3 RISIKOANALYSE
< 100%
Eintrittswahrscheinlichkeit
80%
60%
40%
20%
vermindern
akzeptieren
3a
begrenzen
vermeiden
verlagern
> 0%
0 20 40 60 80 100
Schadenswert
1
6 7
3b
Abbildung 3.2 grafische Risikobewertung
Schwellwerte oder ähnliche Konstrukte können nicht existieren. Letztlich ist
allen Risiken mit einer sinnvollen Strategie zu begegnen.
Zweiter auffälliger Punkt in der grafischen Darstellung sind die bereits
eingezeichneten Maßnahmen zur Risikobegegnung, die sich je nach Tragweite
– also nach Kombination aus Eintrittswahrscheinlichkeit und Schadenswert –
unterscheiden. Diese stellen generell empfehlenswerte Handlungsstrategien
dar und werden im folgenden Abschnitt näher betrachtet.
3.3 Maßnahmen zur Risikobegegnung
Nachdem die Projektrisiken identifiziert und objektiv bewertet wurden, stellt
sich die Aufgabe Strategien zur Risikobegegnung zu entwickeln. Dabei wollen
zweierlei Aspekte betrachtet werden:
28 Danilo Kempf
5
2
4

MASSNAHMEN ZUR RISIKOBEGEGNUNG 3.3
Aktion
Zunächst erweist es sich als sinnvoll, aktiv auf die identifizierten Risiken
einzuwirken, um entweder deren Eintrittswahrscheinlichkeit oder
deren Schadenswert im Eintrittsfalle zu reduzieren und damit die Auswirkungen
auf das Projekt zu minimieren. Welchen Charakter die aktiven
Maßnahmen zur Risikobegegnung tragen sollten ist im Diagramm
schlüsselwortartig eingetragen.
Es ist nicht nur sinnvoll, abstrakt aktive Maßnahmen zu definieren, es ist
auch erforderlich, diese konkret in den Projektstrukturplan durch Definieren
neuer oder Erweitern bestehender Arbeitspakete aufzunehmen.
(Siehe auch 6 Projektstrukturplan 〈S. 41〉.)
Reaktion
Trotz sorgfältigster aktiver Risikobegegnungsmaßnahmen dürfte sich
das Eintreten einiger Projektrisiken nicht vermeiden lassen. Aus diesem
Grund will vorab eine Strategie ausgearbeitet sein, welche reaktiven
Maßnahmen im Eintrittsfalle zu treffen sind.
Im Rahmen dieses Projektes soll den genannten Risiken wie folgt begegnet
werden:
1 Risiko
ehemalige Mitarbeiter der AFP GmbH
Bemerkungen
Zunächst ist es überraschend, daß ein Teil der eigenen Projektmitarbeiter
das höchste Projektrisiko darstellt. Dies ist natürlich
keinesfalls ideal, günstiger wäre es, ein anderes Projektteam zu
wählen. Im vorliegenden Fall ist dies natürlich schlecht möglich, da
diese Mitarbeiter durch ihre Kenntnis der AFP-Schnittstelle Kernqualifikationen
aufweisen, die andere Mitarbeiter nicht zum Projekt
beitragen könnten.
Maßnahmen
Die aktiven Maßnahmen der Risikobegegnung schlagen sich
zunächst in der Stakeholderkommunikation nieder und wurden bereits
im vorangegangenen Kapitel erläutert. Weiterhin stellt im
vorliegenden Fall bereits die Gliederung des Projektes in Arbeitspakete
eine Maßnahme der Risikobegegnung dar – einzig kritisch
ist das Dokumentieren der AFP-Schnittstelle, das unbedingt durch
die Mitarbeiter mit den entsprechenden Kenntnissen durchgeführt
werden muß.
Beim Erstellen der Schnittstellendokumentation handelt es sich um
einen durchaus meßbaren Prozeß (siehe 6.3.1 AFP-Schnittstelle dokumentieren
(1.1.1) 〈S. 47〉), hier kann also von vornherein festgestellt
werden, inwiefern sich tatsächlich aktiver oder passiver
Widerstand der Projektmitarbeiter niederschlägt. Schlimmstenfalls
wäre eine Projektdurchführung auch ganz ohne diese Mitarbeiter
zumindest denkbar.
08-045 Kempf Danilo.pdf 29

3 RISIKOANALYSE
2 Risiko
mangelnde Akzeptanz der Lösung
Bemerkungen
Nächstes Projektrisiko ist die möglicherweise mangelnde Akzeptanz
der Lösung seitens des Kunden. Die Imaginary Networks AG
hatte sich ursprünglich ja für die AFP NetStar-Lösung und gegen
die Telco-Soft TelAPI-Lösung entschieden. Dieses Projekt resultiert
nun darin, daß der Kunde letztlich doch wieder mit der ehemals
abgelehnten Telco-Soft-Lösung konfrontiert wird. Zwar geschieht
dies durchaus einvernehmlich mit dem Kunden, dennoch mag es
Widerstände geben, da, auch durch den Charakter der Lösung, an
der technischen Basis gezweifelt werden könnte.
Maßnahmen
Diesem Risiko wird hauptsächlich im Rahmen der Stakeholderkommunikation
begegnet. Es ist erforderlich, die Telco-Soft GmbH als
kompetentes, schnell reaktionsfähiges Unternehmen und als vertrauensvollen
Partner zu präsentieren. Siehe 2.3 Stakeholderportfolio
und Stakeholdersteuerung 〈S. 19〉.
3a Risiko
CeBIT-Termin nicht haltbar
Bemerkungen
Das eventuelle Nichteinhalten des CeBIT-Termins ist ein geringes
Projektrisiko. Zwar hat als Projektziel dieser Termin eine recht hohe
Priorität, da eine Messe eine gute Gelegenheit ist, Akzente zu setzen
und beim Kunden die nötige Zuversicht zu schaffen – dennoch
verursacht ein Nichteinhalten dieses Termins keinen allzugroßen
Schaden. Trotzdem wird er natürlich (siehe 7 Ablauf- und Terminplanung
〈S. 51〉) im Zuge der Ablauf- und Terminplanung als wichtiger
Meilenstein angesehen.
Maßnahmen
Es wird, um die Einhaltung des Termins sicherzustellen, ein eigenes
Arbeitspaket (1.3.2) definiert, dem eigene Einsatzmittel zugeteilt
werden, dessen Inhalt die Erstellung einer speziellen Messeversion
der Software ist.
3b Risiko
Projektabschlußtermin nicht haltbar
Maßnahmen
Einem verspäteten Projektabschluß kann – ebenfalls durch die
technischen Unwägbarkeiten bedingt – kaum entgegengewirkt
werden. Letztlich muß durch dezidierte Fortschrittsgradmessung
der Projektfortschritt regelmäßig kontrolliert werden und es muß,
so Verzug auftreten sollte, durch für den Einzelfall geeignete Maßnahmen
aktiv entgegengesteuert werden.
30 Danilo Kempf

4 Risiko
Umsetzbarkeit nicht sichergestellt
MASSNAHMEN ZUR RISIKOBEGEGNUNG 3.3
Maßnahmen
Dem vierten Projektrisiko läßt sich wiederum aktiv entgegenwirken.
Ganz aufheben läßt es sich freilich nicht – stellt sich heraus,
daß eine Adapterlösung technisch nicht umsetzbar ist, so läßt sich
an diesem Fakt wohl kaum rütteln. Es kann jedoch zumindest in
der Analysephase für umfangreiche Dokumentation gesorgt werden,
so das sich solche Probleme bereits frühzeitig in der Entwurfsphase
äußern und eben im schlimmsten Falle frühzeitig zu einem
Projektabbruch führen um damit dann wenigstens die Projektkosten
niedrig zu halten.
5 Risiko
Qualität nicht ausreichend
Maßnahmen
Möglichen Qualitätsproblemen läßt sich ebenfalls aktiv entgegensteuern.
Maßnahmen sind dabei allein schon das Erstellen von
Dokumentation und eines konkret ausformulierten Fachkonzeptes
und Softwareentwurfes in der Analyse- und in der Entwurfsphase.
Schon dieses Dokumentieren, das in vielen Softwareunternehmen
durchaus vernachlässigt wird, sichert schon ein gewisses Maß an
Qualität und gibt für die Implementierung eine klare Marschroute
vor.
Zur Qualitätssicherung trägt ebenso bei, daß, während der Softwareentwurf
erstellt wird, auch bereits ein umfangreiches Testprotokoll
definiert wird, das sich an diesem Softwareentwurf orientiert.
So kann leicht eine hohe Abdeckung der zu testenden Merkmale
sichergestellt werden.
Bereits während der Umsetzungsphase und natürlich in großem
Maße während der Testphase werden durch automatisierte Tests
oder manuelles in-Augenschein-nehmen verschiedene Qualtitätsaspekte
der Software geprüft.
6 Risiko
Überlastung des Projektteams
Bemerkungen
Der Überlastung des Projektteams aus Sicht der Projektleitung
aktiv schwerlich entgegenzuwirken. Letztlich bleibt es, aufgrund
der Wahl der Einflußorganisation, dem Auftraggeber vorbehalten,
auch während des Projektverlaufes Prioritäten anders zu setzen
und Projektmitarbeiter wieder zu Linientätigkeiten oder zur Mitarbeit
in anderen Projekten zu verpflichten.
Maßnahmen
Sollten solche Entscheidungen getroffen werden, gerät das Projekt
natürlich in Verzug – das Ressourcenrisiko wandelt sich hier also
08-045 Kempf Danilo.pdf 31

3 RISIKOANALYSE
schnell in ein Terminrisiko. Reaktiv wird sich dies in einer Anpassung
der Termin- und/oder der Einsatzmittelplanung niederschlagen
müssen.
Aktiv kann einer Überlastung durch enge Abstimmung mit dem
Auftraggeber über die Ressourcenauslastung entgegengesteuert
werden.
7 Risiko
Überlastung der Laborkapazität
Bemerkungen
Gleiches wie bei 6 gilt im Prinzip für das letzte Projektrisiko –
die mögliche Überlastung der verfügbaren Ressourcen im Testlabor.
Dabei handelt es sich zwar nur um technische Einsatzmittel,
die grundsätzlich, falls eine Überlastungssituation eintreten und
hinreichend Investitionsbereitschaft vorhanden sein sollte, schnell
beschaffbar wären – der nötige Integrationsaufwand in Kombination
mit dem verhältnismäßig geringem Projektumfang verbietet
dies jedoch. Aktive Maßnahmen lassen sich also schlechterdings
auch hier nicht festlegen. Im Eintrittsfalle wird also auch hier die
Einsatzmittel- und damit vermutlich auch die Terminplanung anzupassen
und mit einer verlängerten Projektdauer zu leben sein.
Maßnahmen
Stetige Abstimmung mit dem Auftraggeber über die Ressourcenauslastung.
32 Danilo Kempf

Projektorganisation 4
4.1 Art der Projektorganisation
Für die Wahl einer Projektorganisationsform bestehen drei Alternativen, die
zu evaluieren sind. Dies sind im Einzelnen:
Reine Projektorganisation
Bei dieser – mithin saubersten – Organisationsform verlassen die Mitarbeiter
für die Projektdauer die Linie und arbeiten ausschließlich im
Projekt. Erst nach Projektende kehren Sie wieder zu ihren Linienaufgaben
zurück.
Matrixorganisation
Bei der Matrixorganisation besteht die Einordnung der Projektmitarbeiter
in die Linienstrukturen weiter. Die Projektmitarbeiter sind dabei aber
nicht nur der Linue, sondern zusätzlich auch dem Projekt organisatorisch
zugehörig. Letztlich kann dies und die damit einhergehende Unterordnung
unter zwei Weisungsbefugnis-Verhältnisse im Projektverlauf zu
Konflikten führen.
Einflußorganisation
Bei dieser Organisationsform (auch Stabsorganisation) bleibt die Linienstruktur
ebenfalls erhalten. Der Projektleiter hat im Prinzip keinerlei
tatsächliche Verantwortung und kann im Zuge seiner Funktion lediglich
auf die Linienstrukturen und die dortigen Weisungsbefugten einwirken.
4.2 Wahl einer Projektorganisation
4.2.1 Stammorganisation
Bei der Telco-Soft GmbH handelt es sich um ein relativ kleines Unternehmen
mit ca. 30 Mitarbeitern und einer sehr flachen Hierarchie, die aus drei Ebenen
besteht, die jeweils direkt der Geschäftsführung unterstellt sind.
Auf der Entwicklungsebene wird jedes Produkt – je nach Umfang und Komplexität
– von einem einzelnen Entwickler oder einem kleinen Team von
zwei oder drei Entwicklern betreut. Die Entwicklungsebene wird durch den
Geschäftsführer Michael Sieber geleitet.
08-045 Kempf Danilo.pdf 33

4 PROJEKTORGANISATION
Orthogonal dazu bestehen auf der Technikebene weitere Teams, deren Aufgaben
Dokumentation, Qualitätssicherung und Support sind. Diese Teams
sind keinem Entwicklerteam fest zugeordnet, sondern wickeln ihre Aufgaben
unternehmensweit koordiniert für alle Entwicklerteams ab. Die Technikebene
wird durch den Geschäftsführer Burkhard Römer geleitet.
Weiterhin sind mehrere Mitarbeiter in der Unternehmensführung und
-organisation beschäftigt.
Organisatorisch stellt sich die Stammorganisation wie in Abbildung 4.1 wiedergegeben
dar. Eine alternative aber gleichwertige Darstellung findet sich
(um die tatsächliche Projektorganisationsform ergänzt) in Abbildung 4.2.
4.2.2 Projektorganisation
Organisationsebene
Geschäftsführung
Entwicklung
Entwicklung Produkt 1
Entwicklung Produkt 2
. . .
Entwicklung Produkt n
Technik
Qualitätssicherung
Dokumentation
Support
Unternehmensführung/Organisation
Abbildung 4.1 Stammorganisation
Für die Gestaltung der Projektorganisation standen die drei im vorangehenden
Abschnitt erläuterten Alternativen zur Wahl, letztlich wurde die Einflußorganisation
als günstigste Alternative ausgewählt.
Reine Projektorganisation
Zur Umsetzung einer reinen Projektorganisation würden die Projektmitarbeiter
für die Dauer des Projektes aus ihrer Linientätigkeit herausgenommen
und fest dem Projekt zugeordnet werden. Mehrere Faktoren
sprechen klar gegen diese Form der Projektorganisation:
• die geringe Unternehmensgröße
• der verhältnismäßig kleine Umfang des Projektes
34 Danilo Kempf

WAHL EINER PROJEKTORGANISATION 4.3
• die Notwendigkeit parallel zum Projekt die Linienaufgaben fortzusetzen
Matrixorganisation
Theoretisch ideal für das Projekt wäre die Matrixorganisation. Die Projektaufgaben
lassen sich grob derart gliedern, daß sie der durch die
Stammorganisation vorgegebenen Struktur entsprechen. Für das Projekt
ist – neben den Aufgaben des Projektmanagements – Entwicklungs-,
Dokumentations- und Qualitätssicherungsleistung zu erbringen.
Wie in Abschnitt 4.2.1 Stammorganisation 〈S. 33〉 gezeigt, ist die Telco-
Soft GmbH mit Entwickler- und unterstützenden Technik-Teams bereits
grundsätzlich matrixartig organisiert. Bei der geringen Unternehmengsgröße
scheint ein projektspezifisches Überlagern dieser Matrixstruktur
wenig sinnvoll.
Einflußorganisation
Letzten Endes handelt es sich beim vorliegenden Projekt überwiegend
um Koordinations- und Steuerungsaufgaben unter Einflußnahme des
Auftraggebers. Die Umsetzung findet innerhalb der gewohnten Linienstrukturen
statt. Aus diesem Grund erscheint eine Einflußorganisations
als die sinnvollste und den gegebenen Strukturen am besten angepaßte
Form der Projektorganisation.
4.2.3 Grafische Darstellung der Projektorganisation
Die in den vorangegangenen Abschnitten erläuterte Organisationsform ist in
Abbildung 4.2 grafisch dargestellt.
Entwicklung
Entwicklung Produkt 1
Entwicklung Produkt 2
. . .
Entwicklung Produkt n
Geschäftsführung
Technik
Qualitätssicherung
Dokumentation
Support
Abbildung 4.2 Projektorganisation
Projektleiter
Organisation
08-045 Kempf Danilo.pdf 35

4 PROJEKTORGANISATION
4.3 Eskalation und Entscheidungsgremien
Üblicherweise exstiert für die Entscheidungsfindung ein mehrstufiger Eskalationsweg,
etwa in der folgenden Form:
Lenkungsausschuß
Projektauftraggeber/Projektausschuß
Projektleiter
Abbildung 4.3 ein üblicher Eskalationsweg
Die Begriffe Projektausschuß und Lenkungsausschuß sind hier natürlich relativ
abstrakt, in der Praxis könnte es sich beim Projektausschuß bzw. beim Projektauftraggeber
und Mitglieder der Abteilungsleiterebene handeln, während
der übergeordnete Lenkungsausschuß auf der Vorstandsebene angesiedelt ist.
Aufgrund der Unternehmensgröße und der sehr flachen Hierarchie ist im
vorliegenden Projekt ein solcher mehrstufiger Eskalationsweg nicht denkbar.
Der tatsächliche Weg ist grafisch folgendermaßen zu repräsentieren:
Auftraggeber
Projektleiter
Abbildung 4.4 tatsächlicher Eskalationsweg
Alle Entscheidungen über den Projektverlauf werden vom Auftraggeber,
also den Geschäftsführern der Telco-Soft GmbH, unter Mitwirkung der Projektleitung
getroffen.
Während des Projekts gilt – wie in der übrigen Unternehmenstätigkeit
ohnehin – eine eine Kommunikation auf kurzem Dienstweg. Generell gibt es
ständigen Kontakt zwischen allen Projektbeteiligten, Hierarchien existieren
nicht. Alle Schritte werden im Vorfeld besprochen und abgestimmt. Entscheidungen
werden durch den Projektleiter an die Mitglieder des Projektteams
zur Umsetzung weitergegeben.
36 Danilo Kempf

Phasenplanung 5
5.1 Beschreibung der Projektphasen
In Abstimmung mit dem Auftraggeber wurde das Projekt in folgende Phasen
gegliedert – dabei folgt es grundsätzlich dem klassischen Phasenmodell
(Wasserfallmodell) der Softwareentwicklung:
Projektplanung
Beginnend mit 1 umfaßt diese erste Phase die Projektplanung. Wesentliche
Teile der Aufgaben des Projektmanagements finden in dieser
Phase statt, große Teile dieses Transfernachweises geben die in der Projektplanungsphase
durchgeführen Planungsschritte wieder.
Diese Phase endet mit dem Meilenstein 2.
Analyse
In der Analysephase wird die Telefonieschnittstelle der AFP GmbH in
Augenschein genommen und durch die an ihrer Entwicklung beteiligten
ehemaligen Mitarbeiter der AFP GmbH dokumentiert. Die Dokumentation
wird den Entwicklern der Telco-Soft-Schnittstelle präsentiert.
Gleichermaßen wird die vorhandene Dokumentation der Telco-Soft-
Schnittstelle den ehemaligen Entwicklern der AFP GmbH präsentiert.
Parallel wird eine Laborumgebung etabliert, in der die Software der
Imaginary Networks AG mit der AFP-Schnittstelle installiert wird.
Durch Anfertigen von Protokollen wird dokumentiert, wie die AFP-
Schnittstelle durch die Software der Imaginary Networks AG genutzt
wird. Von der Imaginary Networks AG wird interne Dokumentation
bezüglich der Netzzugangsschnittstelle bezogen und in Augenschein
genommen.
Die Analysephase endet mit dem Meilenstein 3.
Entwurf
In der Entwurfsphase wird die in der vorangegangenen Analysephase
erstellte interne sowie bezogene externe Dokumentation zur Definition
der Architektur der zu schaffenden Adapterlösung herangezogen.
Es wird ein vollständiger und formal niedergelegter Softwareentwurf
erstellt.
Die Entwurfsphase ist durch Erreichen des Meilensteints 4 beendet.
Implementierung
In der Implementierungs- bzw. Umsetzungsphase wird der Software-
08-045 Kempf Danilo.pdf 37

5 PHASENPLANUNG
Test
entwurf implementiert. Parallel dazu wird technische Dokumentation
erstellt. Die Umsetzungsphase umspannt 5 und ist mit 6 beendet.
In der Testphase wird überprüft, ob die Software den festgelegten Erfordernissen
hinsichtlich der Qualität, Korrektheit und Robustheit entspricht.
Ermittelte Defekte werden durch die Softwareentwickler behoben.
Diese Phase endet mit dem Meilenstein 7.
Abschluß
Das Projekt wird an den Kunden übergeben. Nach erfolgter Abnahme
ist der Meilenstein 8 erreicht. Anschließend wird die Projektdokumentation
erstellt und das Projekt ist mit Erreichen des Meilensteins 9 beendet.
Da es sich bei diesem Projekt um ein Entwicklungsprojekt handelt, sind
die Analyse- und Entwurfsphasen inhaltlich und die Umsetzungsphase zeitlich
erheblich umfangreicher als die weiteren Projektphasen. Der Phasenumfang
ergibt sich im späteren Verlauf der planerischen Arbeiten aus der Ablauf- und
Terminplanung. Greift man dem vor, ergeben sich für die einzelnen Projektphasen
folgende Zeitdauern:
5.2 Meilensteinliste
Projektphase Dauer
Planung 0,5 Wochen
Analyse 3,5 Wochen
Entwurf 4 Wochen
Implementierung 10 Wochen
Test 3 Wochen
Abschluß 2 Wochen
Folgende Meilensteine gelten für das Projekt:
1 – Projektstart
Dieser Meilenstein kennzeichnet den Projektstart.
2 – Projektplanung abgeschlossen
Dieser Meilenstein ist erreicht, wenn die Projektplanung abgeschlossen
ist und ein Projektfinanzierungsplan erstellt ist.
3 – Analysephase abgeschlossen
Der dritte Meilenstein ist erreicht, wenn die Analysephase abgeschlossen
ist – also, wenn die interne Dokumentation erstellt ist und die Softwareentwickler
mit beiden Systemen vertraut sind.
38 Danilo Kempf

VERANSCHAULICHUNG DER PROJEKTPHASEN 5.3
4 – Entwurfsphase abgeschlossen
Dieser Meilenstein ist erreicht, wenn ein Datenverarbeitungskonzept
und ein vollständiger und formaler Softwareentwurf vorliegen.
5 – CeBIT 2008
Dieser Termin-Meilenstein wird durch den Beginn der CeBIT 2008 definiert
und ist fest an den 4. März 2008 geknüpft.
6 – Umsetzung abgeschlossen
Meilenstein 6 ist erreicht, wenn der in der Entwurfsphase geschaffene
Softwareentwurf vollständig umgesetzt und dokumentiert ist.
7 – Testphase abgeschlossen
Dieser Meilenstein ist erreicht, wenn die Software keinerlei Defekte
mehr aufweist, deren Dringklichkeit als kritisch oder als hoch eingestuft
wird.
8 – Inbetriebnahme beim Kunden abgeschlossen
Der achte Meilenstein ist erreicht, wenn die Software bei der Imaginary
Networks AG im Testlabor installiert und in Betrieb genommen ist.
9 – Projektende
Dieser Meilenstein markiert das Projektende und ist erreicht, wenn die
Erstellung der Projektdokumentation abgeschlossen ist.
5.3 Veranschaulichung der Projektphasen
Die Ergebnisse der Phasenplanung – also die Projektphasen und die Meilensteine
– sind in Abbildung 5.1 grafisch dargestellt. Dabei richtet sich die Breite
der Darstellung proportial nach der veranschlagten Phasendauer – in die Grafik
sind also die Ergebnisse der Ablaufplanung bereits eingeflossen.
Phase
1
2
3 4 5
Zeit
6
7
8
9
Abbildung 5.1 Grafischer Phasenplan
Planung
Analyse
Entwurf
Implementierung
Test
Abschluß
08-045 Kempf Danilo.pdf 39

Projektstrukturplan 6
6.1 Darstellung und Codierung des PSP
Für dieses Projekt wurde ein funktionsorientierter Projektstrukturplan gewählt.
Dies ist primär aufgrund persönlicher Präferenz geschehen, da sich wesentliche
Teile der Projektphasenplanung relativ gut in einen solchen funktionsorientierten
PSP übernehmen lassen. Ein objektorientierter Projektstrukturplan
wäre aber gleichermaßen denkbar gewesen.
Die im Folgenden jeweils in der ersten Spalte angegebene Nummer hat
keinerlei projektplanerische Relevanz. Sie wird jedoch vom genutzten Planungstool
automatisch vergeben und erleichtert die Korrelation der hier
wiedergegebenen Vorgänge mit dem Planungstool.
Nr PSP-Code Vorgang
1 1 Projekt Schnittstellenmigration/netzintegrierter Anrufbeantworter
durchführen
2 1.1 Analysieren
3 1.1.1 AFP NetStar-Schnittstelle dokumentieren
4 1.1.2 NetStar-Schnittstellendokumentation präsentieren
5 1.1.3 TelAPI-Schnittstellendokumentation präsentieren
6 1.1.4 Softwareanalyse im Testlabor durchführen
7 1.1.5 Imaginary Networks-Dokumentation sichten
8 1.2 Lösung entwerfen
9 1.2.1 Fachkonzept erstellen
10 1.2.2 Brainstorming durchführen
11 1.2.3 Softwarearchitektur definieren
12 1.2.4 Testprotokoll definieren
13 1.3 Softwareentwurf umsetzen
14 1.3.1 implementieren
15 1.3.2 CeBIT-Version erstellen
16 1.3.3 begleitende Funktionstests durchführen
17 1.3.4 dokumentieren
08-045 Kempf Danilo.pdf 41

6 PROJEKTSTRUKTURPLAN
18 1.4 Testen
19 1.4.1 verifizieren und Defekte beheben
20 1.4.2 analysieren und profilieren, Probleme beseitigen
21 1.4.3 Dokumentation prüfen
22 1.5 in Betrieb nehmen
23 1.5.1 Installationspaket erstellen
24 1.5.2 Abnahme mit Auftraggeber durchführen
25 1.5.3 Lösung bei der Imaginary Networks AG in Testbetrieb
nehmen
26 1.6 Projektmanagement durchführen
27 1.6.1 Projektplanung erstellen
28 1.6.2 Meilensteine kontrollieren
29 1.6.2.1 1 – Projektstart
30 1.6.2.2 2 – Projektplanung abgeschlossen
31 1.6.2.3 3 – Analysephase angeschlossen
32 1.6.2.4 4 – Entwurfsphase abgeschlossen
33 1.6.2.5 5 – CeBIT 2008
34 1.6.2.6 6 – Umsetzungsphase abgeschlossen
35 1.6.2.7 7 – Testphase abgeschlossen
36 1.6.2.8 8 – Inbetriebnahme abgeschlossen
37 1.6.2.9 9 – Projekt vollständig abgeschlossen
38 1.6.3 begleitendes Projektmanagement durchführen
39 1.6.4 Projektdokumentation erstellen
Der hier tabellarisch aufgezeichnete Projektstrukturplan ist auf der folgenden
Seite in einer grafischen Darstellung wiedergegeben.
Zu beachten ist, daß sich die Phasenplanung nicht 1:1 übernommen wurde.
So ist die Planungsphase komplett in der Teilaufgabe 1.6 Projektmanagement
durchführen aufgegangen. Ebenso ist die Projektabschlußphase im PSP
so nicht zu erkennen – sie umfaßt hier die Teilaufgabe 1.5 in Betrieb nehmen
sowie das Arbeitspaket 1.6.4 Projektdokumentation erstellen.
Im realen Projektverlauf war der PSP etwas umfangreicher und technisch
präziser. Ich habe dies für den Transfernachweis etwas abstrahieren
müssen.
42 Danilo Kempf

1 Projekt Schnittstellenmigration/netzintegrierter Anrufbeantworter
durchführen
Projekt Teilaufgaben Arbeitspakete
1.6 Projektmanagement
durchführen
1.5 in Betrieb nehmen
1.4 Testen
1.3 Softwareentwurf
umsetzen
1.2 Lösung entwerfen
1.1 Analysieren
1.6.1 Projektplanung
erstellen
1.5.1 Installationspaket
erstellen
1.4.1 verifizieren
und Defekte beheben
1.3.1 implementieren
1.2.1 Fachkonzept
erstellen
1.1.1 AFP NetStar-
Schnittstelle dokumentieren
1.6.2.1 1
DARSTELLUNG UND CODIERUNG DES PSP 6.1
1.6.2.2 2
1.6.2 Meilensteine
kontrollieren
1.3.2 CeBIT-Version
erstellen
1.2.2 Brainstorming
durchführen
1.6.2.3 3
1.5.2 Abnahme
mit Auftraggeber
durchführen
1.4.2 analysieren
und profilieren,
Probleme beheben
1.1.2 NetStar-
Schnittstellendokumentation
präsentieren
1.6.2.4 4
1.6.2.5 5
1.6.3 begleitendes
Projektmanagement
durchführen
1.5.3 Lösung in
Testbetrieb nehmen
1.4.3 Dokumentation
prüfen
1.3.3 begleitende
Funktionstests
durchführen
1.2.3 Softwarearchitektur
definieren
1.1.3 TelAPI-
Schnittstellendokumentation
präsentieren
1.6.2.6 6
1.6.2.7 7
1.6.4 Projektdokumentation
erstellen
1.3.4 dokumentieren
1.2.4 Testprotokoll
definieren
1.6.2.8 8
1.1.4 Softwareanalyse
im Testlabor
durchführen
1.6.2.9 9
1.1.5 Imaginary
Networks-
Dokumentation
sichten
08-045 Kempf Danilo.pdf 43
Abbildung 6.1 Grafische Darstellung des Projektstrukturplans

6 PROJEKTSTRUKTURPLAN
6.2 Projektmanagement im PSP
Die Aufgaben des Projektmanagement finden sich im Projektstrukturplan unterhalb
der Teilaufgabe 1.6.
Grundsätzlich sind die Aufgaben des Projektmanagement in drei Arbeitspakete
aufgeteilt. Diese sind:
• 1.6.1 Projektplanung erstellen
• 1.6.4 begleitendes Projektmanagement durchführen
• 1.6.4 Projektdokumentation erstellen
Zusätzlich dazu besteht noch die Teilaufgabe 1.6.2 Meilensteine kontrollieren
unterhalb der planerisch die Projektmeilensteine angeordnet sind.
Die einzelnen Arbeitspakete werden im Folgenden beschrieben.
6.2.1 Projektplanung erstellen
In diesem Arbeitspaket, dessen Ergebnis allen anderen Arbeitspaketen im
Projektablauf vorangestellt ist, wird die Projektplanung vollzogen. Dieses Arbeitspaket
beinhaltet folgende Aufgaben:
• Umfeld-, Stakeholder- und Risikoanalyse
• Phasenplanung
• Entwickeln des Projektstrukturplans
• erste Ablauf- und Terminplanung
• Einsatzmittel- und Kostenplanung
Die Projektplanung wird durch mich, den Projektleiter, unter den Maßgaben
des Auftraggebers durchgeführt. Letztlich ist Projektmanagement bzw.
Projektplanung natürlich ein stetiger Prozeß. So umfaßt das Arbeitspaket
1.6.1 zwar das erste Erstellen der Projektplanung – diese ist damit aber in keinem
Falle als abgeschlossen zu betrachten. Durch externe Einflüsse, neue Situationen
oder Erkenntnisse ist die Projektplanung einem über den gesamten
Projektablauf andauernden Wandel unterlegen und muß stetig und ständig
angepaßt werden. Inbesondere die Risikoanalyse will – um effektiv sein zu
können – regelmäßig vollzogen werden. Gleichermaßen muß, durch projektexterne
Einflüsse getrieben, sicher auch die Einsatzmittelplanung und dadurch
bedingt schlimmstenfalls auch die Terminplaung über den Projektverlauf
hin angepaßt werden.
In diesem Schritt wird auch das Projekthandbuch erstellt, das für die Projektbeteiligten
alle projektbezogenen Regelungen und Informationen zusammenfaßt.
44 Danilo Kempf

PROJEKTMANAGEMENT IM PSP 6.2
Aufgrund der geringen Unternehmens- und Projektgröße wurde tatsächlich
kein richtiges Projekthandbuch erstellt. Letztlich wurde in der genutzten
Intranet-/Groupware-Lösung ein projektspezifischer Bereich eingerichtet,
der mit vielen projektplanerischen und technischen Informationen gefüllt
wurde – dieser stellt ein elektronisches, stetigem Wandel unterzogenes
Äquivalent zum Projekthandbuch dar.
6.2.2 begleitendes Projektmanagement durchführen
Parallel zum Projektablauf ist das Arbeitspaket 1.6.3 angeordnet, das alle projektbegleitenden
Aufgaben des Projektmanagement-bezogenen Aufgabenbereiches
umfaßt. Dabei handelt es sich insbesondere um die Fortsetzung der
im vorangegangenen Abschnitt geschilderten Planungsaufgaben, aber auch
um das Wahrnehmen von Kontrollfunktionen, das Durchführen der bereits
erwähnten Projektbesprechungen und die Stakeholder-Kommunikation in ihrer
Gesamtheit.
Weiterhin wird in diesem Arbeitspaket auch stetig der Projektfortschritt
ermittelt und mit dem Auftraggeber abgeglichen. Eventuelle Defizite
bzw. Rückstände werden durch geeignete Meß- bzw. Analyseverfahren
ermittelt und durch konkrete Handlungen in enstprechend umzusetzende
Lösungsschritte kanalisiert.
Dieses Arbeitspaket ist wieder durch den geringen Projektumfang und
durch den Charakter des Projekts, bei dem es sich um ein reichlich lineares
Entwicklungsprojekt handelt, bedingt. Letztlich faßt es sehr viele Aufgaben,
die in größeren Projekten einzelne Arbeitspakete darstellen, die dann auch in
der Ablaufplanung spezifischen Zeitpunkten zugeordnet werden können, zu
einer Einheit zusammen.
Durch diese Zusammenfassung stellt sich in der Ablaufplanung (7 Ablaufund
Terminplanung 〈S. 51〉) das Problem, daß dieses Arbeitspaket prinzipiell
über die gesamte Projektdauer gestreckt werden müßte. Durch den relativ geringen
Umfang der Aufgaben und den wöchentlich geringen Zeitbedarf halte
ich das Zusammenfassen zu einem Arbeitspaket für durchaus gerechtfertigt.
6.2.3 Projektdokumentation erstellen
Im Anschluß an die Projektdurchführung wird von mir das Arbeitspaket 1.6.4
durchgeführt. Dieses umfaßt die Erstellung der Projektdokumentation, die den
Charakter eines umfangreichen Projektabschlußberichtes trägt.
Diese Dokumentation gibt Aufschluß über den tatsächlichen Projektverlauf
und über das Projektergebnis, sollte letzteres von der konkreten Zieldefinition
abweichen.
In letzter Instanz wird in diesem Arbeitsschritt ein umfangreiches Do-
08-045 Kempf Danilo.pdf 45

6 PROJEKTSTRUKTURPLAN
kumentationspaket erarbeitet, das den Projektverlauf umfangreich analysiert
und nachvollziehbar aufbereitet. Als Anlagen werden der Projektdokumentation
die während der Projektdurchführung erstellten Berichte, Analysen und
Protokolle beigefügt. Die Projektdokumentation wird archiviert und kann
später als Arbeitsgrundlage für Folgeprojekte dienen.
6.3 Arbeitspaketbeschreibungen
Im folgenden ist eine strukturierte Beschreibung dreier Arbeitspakete aus
dem Projektstrukturplan wiedergegeben. Die Arbeitspaketbeschreibungen
enthalten bereits Informationen über Anordnungsbeziehungen untereinander,
konkrete Termine sowie beteiligte Mitarber und Einsatzmittel. Diese Informationen
stehen erst zur Verfügung, nachdem die entsprechenden Planungsschritte,
die in den folgenden Kapitel wiedergegeben sind, vollzogen
sind. Die korrekte Herangehensweise umfaßt zunächst das Erstellen der Arbeitspaketbeschreibungen,
anschließendes Vollziehen der nachgelagerten Planungsschritte
sowie das darauf folgende Aktualisieren der Arbeitspaketbeschreibungen.
Auch Arbeitspaketbeschreibungen müssen, so dies entsprechend kommuniziert
wird, über die Projektdauer keineswegs fest sein, sondern können jederzeit
durch neuere Versionen ersetzt werden.
Für die folgenden Arbeitspaketbeschreibungen will gelten, daß sowohl die
Ablauf-/Termin- als auch die Einsatzmittel- und Kostenplanung bereits abgeschlossen
ist.
46 Danilo Kempf

6.3.1 AFP-Schnittstelle dokumentieren (1.1.1)
ARBEITSPAKETBESCHREIBUNGEN 6.3
Projekt 1 Migration/netzintegrierter Anrufbeantworter
Projektphase 1.1 Analyse
Arbeitspaket 1.1.1 AFP-Schnittstelle dokumentieren
Version v1 Datum 5. November 2007
Voraussetzungen 1.6.2.2 Voraussetzung
für
1.1.2
Anfangstermin 6. November 2007 Endtermin 27. November 2007
Dauer 15 Arbeitstage Aufwand 30 Personentage
Verantwortlich Michael Walm
Beteiligt Michael Walm, Sören Schneider
Ziele Die AFP-NetStar-Schnittstelle ist in einem Format dokumentiert,
das sowohl inhaltlich als auch im Umfang
dem internen Telco-Soft-Standard für Dokumentation entspricht.
Aufgaben Einarbeitung in XML-basiertes Dokumentationsformat
(grundsätzlich vor Projektbeginn erfolgt, ggf. Klärung offener
Fragen mit Jürgen Kurzmann)
Fortschrittsmessung
API-Dokumentation der NetStar-Schnittstelle in Telco-
Soft-Dokumentationsformat übernehmen
interne Call-Control und Media-Access Schnittstelle dokumentieren
Einpflegen der Dokumentation ins Versionskontrollsystem
(nach vorheriger Rücksprache mit Jürgen Kurzmann)
Bei Erstellung von Dokumentation kann der Fortschrittsgrad
nur schwer ermittelt werden. Für dieses Arbeitspaket
wird der Fortschrittsgrad durch das Verhältnis der bereits
dokumentierten zu den insgesamt zu dokumentierenden
API-Methoden ermittelt – dies stellt keine optimale aber
dennoch eine hinreichende Metrik dar.
08-045 Kempf Danilo.pdf 47

6 PROJEKTSTRUKTURPLAN
6.3.2 Softwarearchitektur definieren (1.2.3)
Projekt 1 Migration/netzintegrierter Anrufbeantworter
Projektphase 1.2 Entwurf
Arbeitspaket 1.2.3 Softwarearchitektur definieren
Version v1 Datum 5. November 2007
Voraussetzungen 1.2.2 Voraussetzung
für
1.2.4
Anfangstermin 10. Dezember 2007 Endtermin 19. Dezember 2007
Dauer 8 Arbeitstage Aufwand 16 Personentage
Verantwortlich Martin Riedel
Beteiligt Martin Riedel, Thomas Ernemann
Ziele Die Architektur der zu schaffenden Adapterlösung ist definiert
und in normgerechter Form spezifiziert. Aufbauend
auf dieser Spezifikation kann mit der Implementierung begonnen
werden.
Aufgaben Das Fachkonzept, in dem prinzipiell Aufbau, Informationsflüsse
und Interaktionen der Lösung beschrieben sind,
wird in konkrete Klassenstrukturen umgesetzt.
Fortschrittsmessung
Die entsprechenden Klassen werden bis zur Implementierbarkeit
modelliert.
Der Softwarearchitektur wird in einer Vielzahl von UML2-
Strukturdiagrammen niedergelegt.
Die entstandene Dokumentation wird in das
Versionskontroll- und Dokumentenmanagement-System
eingepflegt.
Der Fortschrittsgrad für dieses Arbeitspaket läßt sich anhand
des Fachkonzeptes ermitteln. Er ergibt sich daraus,
wie viele (prozentual gesehen) im Fachkonzept auf Verhaltensebene
dargestellte bzw. modellierte Artefakte bereits in
hier strukturell modellierte Artefakte umgewandelt wurden.
48 Danilo Kempf

6.3.3 Analysieren, profilieren, Probleme beseitigen (1.4.2)
ARBEITSPAKETBESCHREIBUNGEN 6.3
Projekt 1 Migration/netzintegrierter Anrufbeantworter
Projektphase 1.4 Test
Arbeitspaket 1.4.2 analysieren, profilieren, Probleme beseitigen
Version v1 Datum 5. November 2007
Voraussetzungen 1.2.2 Voraussetzung
für
1.2.4
Anfangstermin 24. März 2008 Endtermin 28. März 2008
Dauer 5 Arbeitstage Aufwand 11 Personentage
Verantwortlich Lothar Karlson
Beteiligt Lothar Karlson zu 100%, Martin Riedel, Thomas Ernemann,
Michael Walm zu je 25%
Ziele Es ist durch Lasttests sichergestellt, daß die Adapterlösung
keine negativen Auswirkungen auf Systemstabilität und
Systemlastverhalten hat.
Aufgaben Installation des Imaginary Networks AG-Lösung im Testlabor.
Fortschrittsmessung
Aufsetzen eines Lastgenerators, Dauertests mit bestehenden
Testmustern
Code-Coverage-Analyse (Koordiniert mit Torben Rahlich/Jens
Wippel und den ggf. vorläufigen Resultaten aus
Arbeitspaket 1.4.1), Profilierungs-Analyse – Abgleichen
der Ergebnisse mit den Entwicklern
Gegebenenfalls Fixes für Problemstellen integrieren, wenn
nicht möglich Bericht an die Projektleitung.
Es erfolgt keine gesonderte Fortschrittsmessung – der Fortschrittsgrad
ist durch den zeitlichen Verlauf des Arbeitspaketes
festgelegt. Ist zu erwarten, daß bis zum geplanten
Ende des Arbeitspakets die Stabilität der Lösung nicht sichergestellt
werden kann, muß dies frühzeitig an den Projektleiter
gemeldet werden.
08-045 Kempf Danilo.pdf 49

Ablauf- und Terminplanung 7
7.1 Vorgangsliste
Im vorangegangenen Kapitel wurde der Projektstrukturplan mit allen für das
Projekt relevanten Arbeitspaketen erstellt. Im Zuge der Ablauf- bzw. Terminplanung
wird diesen Arbeitspaketen eine voraussichtliche Dauer zugeordnet.
Real greift dieser Schritt bereits der Einsatzmittelplanung voraus, da die
geschätzte Dauer der einzelnen Vorgänge bereits im Hinblick auf vermutlich
zur Verfügung stehende Ressourcen geschieht. Letztlich ist die Ablaufplanung
ein mit der Einsatzmittelplanung verzahnter iterativer Prozeß. Siehe
auch 8 Einsatzmittel- und Kostenplanung 〈S. 65〉.
7.1.1 Dauer der Arbeitspakete
Nr PSP-Code Vorgang Dauer
1 1 Projekt Schnittstellenmigration/netzintegrierter
Anrufbeantworter durchführen
2 1.1 Analysieren
3 1.1.1 AFP NetStar-Schnittstelle dokumentieren 15t
4 1.1.2 NetStar-Schnittstellendokumentation
präsentieren
1t
5 1.1.3 TelAPI-Schnittstellendokumentation
präsentieren
1t
6 1.1.4 Softwareanalyse im Testlabor durchführen 8t
7 1.1.5 Imaginary Networks-Dokumentation sichten 10t
8 1.2 Lösung entwerfen
9 1.2.1 Fachkonzept erstellen 5t
10 1.2.2 Brainstorming durchführen 3t
11 1.2.3 Softwarearchitektur definieren 8t
12 1.2.4 Testprotokoll definieren 4t
13 1.3 Softwareentwurf umsetzen
14 1.3.1 implementieren 50t
15 1.3.2 CeBIT-Version erstellen 5t
16 1.3.3 begleitende Funktionstests durchführen 30t
08-045 Kempf Danilo.pdf 51

7 ABLAUF- UND TERMINPLANUNG
17 1.3.4 dokumentieren 20t
18 1.4 Testen
19 1.4.1 verifizieren und Defekte beheben 10t
20 1.4.2 analysieren und profilieren, Probleme
beseitigen
5t
21 1.4.3 Dokumentation prüfen 2t
22 1.5 in Betrieb nehmen
23 1.5.1 Installationspaket erstellen 1t
24 1.5.2 Abnahme mit Auftraggeber durchführen 1t
25 1.5.3 Lösung bei der Imaginary Networks AG in
Testbetrieb nehmen
4t
26 1.6 Projektmanagement durchführen
27 1.6.1 Projektplanung erstellen 3t
28 1.6.2 Meilensteine kontrollieren
29 1.6.2.1 1 – Projektstart –
30 1.6.2.2 2 – Projektplanung abgeschlossen –
31 1.6.2.3 3 – Analysephase abgeschlossen –
32 1.6.2.4 4 – Entwurfsphase abgeschlossen –
33 1.6.2.5 5 – CeBIT 2008 –
34 1.6.2.6 6 – Umsetzungsphase abgeschlossen –
35 1.6.2.7 7 – Testphase abgeschlossen –
36 1.6.2.8 8 – Inbetriebnahme abgeschlossen –
37 1.6.2.9 9 – Projekt vollständig abgeschlossen –
38 1.6.3 begleitendes Projektmanagement durchführen
39 1.6.4 Projektdokumentation erstellen 5t
Die Vorgangsliste weist für alle Arbeitspakete eine Zeitangabe auf. Teilaufgaben
– also Sammlungen von Arbeitspaketen – sind nicht mit einer Zeitangabe
versehen. Grundsätzlich ergibt sich die Dauer einer Teilaufgabe aus der Summe
der in ihr enthaltenen Arbeitspakete, beeinflußt durch die zwischen ihnen
bestehenden Anordnungsbeziehungen.
Den Meilensteinen wurde ebenfalls keine Zeitangabe zugeordnet, im Planungstool
sind diese mit einer Zeitangabe von 0t versehen.
Auffällig ist, daß dem Arbeitspaket 1.6.3 Begleitendes Projektmanagement
durchführen hier noch keine Zeitdauer zugeordnet werden konnte. Dieses
Arbeitspaket umfaßt im Wesentlichen die Stakeholderkommunikation, das
Berichtswesen und projektbegleitende Aufgaben und ist somit im Aufwand
und in seiner Dauer unmittelbar von der Projektdauer abhängig. (Siehe auch
6.2.2 begleitendes Projektmanagement durchführen 〈S. 45〉.)
52 Danilo Kempf

7.1.2 Anordnungsbeziehungen ermitteln
VORGANGSLISTE 7.1
Die in der Vorgangsliste den Arbeitspaketen zugewiesene Zeitdauer ist zur
Terminplanung kein ausreichendes Bemessungskriterium. Zusätzlich müssen
die Arbeitspakete noch durch Feststellen der inhärenten Anordnungsbeziehungen
in eine Reihenfolge gebracht werden.
Folgend ist der um die Anordnungsbeziehungen erweiterte Projektstrukturplan
aufgezeichnet. Aus Platzgründen habe ich hier nur Vorgänger und
Nachfolger wiedergegeben, die Vorgangsdauer ist in dieser Tabelle nicht enthalten.
Ebenfalls teils aus Platzgründen, teils aus der Notwendigkeit heraus,
die hier aufgezeichneten Angaben mit dem genutzen Planungstool abzugleichen,
erfolgt die Angabe der Anordnungsbeziehungen nicht über den PSP-
Code, sondern über die – an sich projektplanerisch bedeutungslose – Vorgangsnummer
des Planungstools.
Eine vollständige Vorgangsliste, die alle hier fehlenden Informationen sowie
auch bereits die ermittelten Zeit- bzw. Terminangaben sowie Pufferzeiten
beinhaltet, ist im Abschnitt vollständige Vorgangsliste 〈S. 109〉 im Anhang dieses
Transfernachweises zu finden.
Nr PSP-Code Vorgang Vorgänger Nachfolger
1 1 Projekt Schnittstellenmigration/netzintegrierter
Anrufbeantworter
durchführen
2 1.1 Analysieren
3 1.1.1 AFP NetStar-Schnittstelle
dokumentieren
4 1.1.2 NetStar-Schnittstellendokumentation
präsentieren
5 1.1.3 TelAPI-Schnittstellendokumentation
präsentieren
6 1.1.4 Softwareanalyse im
Testlabor durchführen
7 1.1.5 Imaginary Networks-
Dokumentation
sichten
30 4
3 31
30 31
30 31
30 31
8 1.2 Lösung entwerfen
9 1.2.1 Fachkonzept erstellen 31 10
10 1.2.2 Brainstorming
durchführen
9 11
08-045 Kempf Danilo.pdf 53

7 ABLAUF- UND TERMINPLANUNG
11 1.2.3 Softwarearchitektur
definieren
10 12
12 1.2.4 Testprotokoll definieren 11 32
13 1.3 Softwareentwurf
umsetzen
14 1.3.1 implementieren 32 15AF+30t,
16AF+20t,
17AF+20t,
34
15 1.3.2 CeBIT-Version erstellen 14AF+30t 33
16 1.3.3 begleitende
Funktionstests
durchführen
14AF+20t 34
17 1.3.4 dokumentieren 14AF+20t 34
18 1.4 Testen
19 1.4.1 verifizieren und Defekte 34 35,
beheben
20AF+3t
20 1.4.2 analysieren und
profilieren, Probleme
beseitigen
19AF+3t 35
21 1.4.3 Dokumentation prüfen 34 35
22 1.5 in Betrieb nehmen
23 1.5.1 Installationspaket
erstellen
24 1.5.2 Abnahme mit
Auftraggeber
durchführen
25 1.5.3 Lösung bei der
Imaginary Networks AG
in Testbetrieb nehmen
35 24
23 25
24 36
26 1.6 Projektmanagement
durchführen
27 1.6.1 Projektplanung erstellen 29 30
28 1.6.2 Meilensteine
kontrollieren
29 1.6.2.1 1 – Projektstart – 27
30 1.6.2.2 2 – Projektplanung
abgeschlossen
27 3, 5, 6, 7, 38
31 1.6.2.3 3 – Analysephase 4, 5, 6, 7 9
abgeschlossen
32 1.6.2.4 4 – Entwurfsphase
abgeschlossen
12 14
54 Danilo Kempf

NETZPLAN 7.2
33 1.6.2.5 5 – CeBIT 2008 15 34
34 1.6.2.6 6 – Umsetzungsphase 14, 16, 17, 19, 21
abgeschlossen
33
35 1.6.2.7 7 – Testphase
abgeschlossen
19, 20, 21 23
36 1.6.2.8 8 – Inbetriebnahme
abgeschlossen
25 39NF-3t
37 1.6.2.9 9 – Projekt vollständig
abgeschlossen
39 –
38 1.6.3 begleitendes
Projektmanagement
durchführen
30 39EF
39 1.6.4 Projektdokumentation 38EF, 37
erstellen
36NF-3t
Hier muß darauf hingewiesen werden, daß Teilaufgaben wiederum keinerlei
Anordnungsbeziehungen aufweisen, da sich auch diese aus den Beziehungen
der enthaltenen Arbeitspakete ergeben. Zwar wäre es möglich, auch
hier Anordnungsbeziehungen aufzuzeichnen, diese würden aber keine neuen
Informationen zur Terminplanung beitragen.
Ist bei den Anordnungsbeziehungen nur eine Zahl angegeben, handelt
es sich um eine Normalfolge ohne zeitlichen Versatz – ist also das
Vorgänger-Arbeitspaket abgeschlossen, beginnt das Nachfolger-Arbeitspaket.
Ist zusätzlich zur Nummer des Vorgänger-Arbeitspakets eine Buchstabenkombination
angegeben, handelt es sich nicht um eine Normalfolge oder aber
um eine Normalfolge mit zeitlichem Versatz. Die Buchstabenkombinationen
sind wie folgt zu interpretieren:
NF Normalfolge, Ende des einen Arbeitspaketes bedingt
den Anfang des anderen Arbeitspaketes
AF Anfangsfolge, Beginnt das eine Arbeitspaket, beginnt
auch das andere Arbeitspaket
EF Endefolge, Ende des einen Arbeitspaketes bedingt
auch das Ende des anderen Arbeitspaketes
SF Sprungfolge (tritt in diesem Projekt nicht auf), ein Arbeitspaket
endet erst, wenn ein anderes Arbeitspaket
begonnen hat.
Weitere Informationen zum Thema und Erläuterungen zu einigen im
konkreten Projekt auftretenden Anordnungsbeziehungen finden sich im Abschnitt
7.3 Anordnungsbeziehungen 〈S. 61〉.
08-045 Kempf Danilo.pdf 55

7 ABLAUF- UND TERMINPLANUNG
7.2 Netzplan
Sind Dauer und Anordnungsbeziehungen der Arbeitspakete und Meilensteine
ermittelt, lassen sich jedem Arbeitspaket bzw. jedem Meilenstein Termine
zuordnen, indem vom Projektstart-Termin aus unter Einhaltung der Anordnungsbeziehungen
die einzelnen Zeitdauer-Angaben der Arbeitspakete aufaddiert
werden. Dies kann erneut in einer um diese Angaben angereicherten
Vorgangsliste wiedergegeben werden – an dieser Stelle sei auf die Anlage
vollständige Vorgangsliste 〈S. 109〉 verwiesen.
Die Terminermittlung erfolgt in zwei Schritten. Zunächst wird dem Projektstarttermin
der Zeitpunkt 0 zugeordnet – von dort ausgehend werden
unter Einhaltung der Anordnungsbeziehung die einzelnen Vorgangsdauern
aufaddiert. Die in diesem Schritt entstehende Liste wird letztlich auf den Projektkalender
abgebildet.
7.2.1 Einsatz der Netzplantechnik
Mit Hilfe der Netzplantechnik lassen sich für jeden Vorgang im Projekt die
verfügbaren Pufferzeiten ermitteln. Diese Pufferzeiten entstehen durch potentielle
Parallelität im Projektablauf und den unterschiedliche Zeitbedarf der
parallel ablaufenden Vorgänge.
Im folgenden ist ein Vorgangsknoten-Netzplan nach der Metra-Potential-
Methode wiedergegeben. Jeder Knoten im Netzplan beschreibt einen Vorgang
im Projekt, die Pfeile zwischen den Knoten geben die Anordnungsbeziehungen
wieder.
Die Netzplantechnik liefert hier interessante Erkenntnisse: Insbesondere
ist auffällig, daß dieses Projekt nur wenig Parallelität aufweist und sich deshalb
nahezu alle Arbeitspakete auf dem kritischen Pfad befinden. Jedes dieser
Arbeitspakete ist, sofern dort eine Verzögerung auftritt, in der Lage, den Projektablauf
für sich genommen zu verzögern.
Wenngleich dies natürlich wenig erstrebenswert erscheint, ist im vorliegenden
Projekt nichts Anderes zu erwarten – es handelt sich um ein recht
kleines Entwicklungsprojekt, bei dem fast jedes Arbeitspaket von den in den
jeweiligen Vorgängern gewonnenen Ergebnissen abhängig sein muß.
Im realen Projektverlauf wurde der PSP nach Ende der Entwurfsphase etwas
ergänzt und das Arbeitspaket 1.3.1 implementieren wurde in eine Teilaufgabe
zu sechs Arbeitspaketen getrennt. Ich habe darauf verzichtet, dies
hier wiederzugeben – wesentlich mehr Parallelitätspotential brachte auch
dies nicht ins Projekt.
56 Danilo Kempf

1.6.2.1 – –
1 – Projektstart
0 0 0
0 0 0
1.6.1 Kempf 3t
Projektplanung erstellen
0 0 3
0 0 3
NETZPLAN 7.2
Die Darstellung des Netzplans erfolgt im Wesentlichen nach DIN
69900-2. Abweichend von dieser Norm habe ich der besseren
Erkennbarkeit wegen darauf verzichtet, die Verbindungspfeile
überlappend darzustellen. Weiterhin ist der kritische Pfad hervorgehoben
( ) wiedergegeben.
Die Knoten in diesem Netzplan sind nach folgendem Schema formatiert:
PSP-Code verantw. Dauer
Titel des Arbeitspakets
FAZ GP FEZ
SAZ FP SEZ
Dabei gelten diese Abkürzungen:
Abkürzung Bedeutung
verantw. Verantwortlicher für das Arbeitspaket
FAZ frühest möglicher Anfangszeitpunkt
FEZ frühest möglicher Endzeitpunkt
SAZ spätest möglicher Anfangszeitpunkt
SEZ spätest möglicher Endzeitpunkt
GP Gesamtpuffer
FP freier Puffer
Durch die Netzplantechnik wird erkennbar, daß das Arbeitspaket
1.6.3 auf dem kritischen Pfad liegt. Weiterhin wird deutlich, daß
der Meilenstein 5 einen zeitlichen Puffer von 25 Tagen hat.
Beides ist tatsächlich nicht der Fall – siehe dazu die Diskussion
im Text.
Abbildung 7.1 Netzplan
1.6.2.2 – –
2 – Projektplanung abgeschlossen
3 0 3
3 0 3
08-045 Kempf Danilo.pdf 57
1.1.1 Walm 15t
NetStar-Schnittstelle dokumentieren
3 0 18
3 0 18
1.1.3 Ernemann 1t
TelAPI-Dokumentation präsentieren
3 15 4
18 15 19
1.1.4 Karlson 8t
Softwareanalyse durchführen
3 8 11
11 8 19
1.1.5 Ernemann 10t
Imaginary Networks-Dokumentation
3 6 13
9 6 19
1.6.3 Kempf 104t
begleitendes Projektmanagement
3 0 107
3 0 107
1.1.2 Walm 1t
NetStar-Dokumentation präsentieren
18 0 19
18 0 19
1.6.2.3 – –
3 – Analysephase abgeschlossen
19 0 19
19 0 19
1.2.1 Riedel 5t
Fachkonzept erstellen
19 0 24
19 0 24
1.2.2 Riedel 3t
Brainstorming durchführen
24 0 27
24 0 27
1.2.3 Riedel 8t
Softwarearchitektur definieren
27 0 35
27 0 35
1.2.4 Rahlich 4t
Testprotokoll definieren
35 0 39
35 0 39
1.6.2.4 – –
4 – Entwurfsphase abgeschlossen
39 0 39
39 0 39
1.3.1 Riedel 50t
implementieren
39 0 89
39 0 89
AF+20t
AF+20t
AF+30t
1.3.3 Wippel 30t
begleitende Funktionstests
59 0 89
59 0 89
1.3.4 Kurzmann 20t
dokumentieren
59 10 79
69 10 89
1.3.2 Kempf 5t
CeBIT-Version erstellen
59 25 64
84 25 89
1.6.2.5 – –
5 – CeBIT 2008
64 25 64
89 0 89
EF
1.6.2.6 – –
6 – Umsetzung abgeschlossen
89 0 89
89 0 89
1.4.1 Rahlich 10t
verifizieren, Defekte beheben
89 0 99
89 0 99
1.4.3 Riedel 2t
Dokumentation prüfen
89 8 91
97 8 99
AF+3t
1.4.2 Karlson 5t
analysieren, profilieren
92 2 97
94 2 99
1.6.2.7 – –
7 – Testphase abgeschlossen
99 0 99
99 0 99
1.5.1 Ernemann 1t
Installationspaket erstellen
99 0 100
99 0 100
1.5.2 Kempf 1t
Abnahme mit Auftraggeber
100 0 101
100 0 101
1.5.4 Rahlich 4t
Testbetrieb bei Imaginary Networks
101 0 105
101 0 105
1.6.2.8 – –
8 – Inbetriebnahme abgeschl.
105 0 105
105 0 105
NF-3t
1.6.4 Kempf 5t
Projektdokumentation erstellen
102 0 107
102 0 107
1.6.2.9 – –
9 – Projekt abgeschlossen
107 0 107
107 0 107

7 ABLAUF- UND TERMINPLANUNG
Weiterhin fällt im hier abgedruckten Netzplan auf, daß sich das Arbeitspaket
1.6.3 begleitendes Projektmanagement durchführen ebenfalls auf dem kritischen
Pfad zu befinden scheint. Dies ist jedoch ein durch das Planungstool
verursachter Trugschluß. Dieses Arbeitspaket ist so definiert, daß es (prinzipiell)
gemeinsam mit dem Projektverlauf beginnt und über das gesamte Projekt
andauert – wenn man so will unterliegt es im Grunde sowohl einer Anfangsals
auch einer Endfolge. Dies läßt sich leider im Planungstool nicht darstellen
und muß durch händisches Nachtragen der Projektdauer als Arbeitspaketdauer
simuliert werden. Dies wiederum führt nun dazu, daß das Planungstool
hier fälschlicherweise von einer Kritizität ausgehen muß, die natürlich in
Wirklichkeit nicht gegeben ist.
Ebenso auffällig ist, daß der Meilenstein 5, der ja den Beginn der Ce-
BIT markiert, zeitlich um 25 Tage beweglich zu sein scheint. Dies ist natürlich
nicht der Fall – eine Erläuterung dazu findet sich im Abschnitt 7.2.3 Terminplanung
〈S. 60〉.
7.2.2 Pufferzeiten
Mit der Netzplantechnik lassen sich für jeden Projektvorgang Pufferzeiten ermitteln.
Diese Pufferzeiten werden aus den jeweiligen Dauer-Angaben der
einzelnen Vorgänge sowie aus deren Anordnungsbeziehungen berechnet. Sie
geben an, inwiefern sich Vorgänge verschieben können, ohne den Projektablauf
zu beeinflussen.
Hauptsächlich können zwei verschiedene Pufferzeiten unterschieden werden.
Daneben existieren weitere, die jedoch im vorliegenden Projekt keine Bedeutung
haben bzw. Anwendung finden.
Gesamtpuffer
Der Gesamtpuffer ergibt sich aus der Differenz von spätest zu frühest
möglicher Anfangs- bzw. Endzeit eines Vorgangs und gibt an, wie weit
ein Vorgang sich verschieben kann, ohne den Projektendtermin negativ
zu beeinflussen.
Freier Puffer
Der freie Puffer gibt an, wie weit sich ein Vorgang verschieben kann, ohne
seine Nachfolger negativ zu beeinflussen. Die Errechnung des freien
Puffers unterscheidet sich je nach Anordnungsbeziehung – für die Normalfolge
ergibt er sich aus der Differenz des frühesten Anfangstermins
des (zeitnähesten) Nachfolgevorgangs und des eigenen frühesten Endzeitpunktes.
58 Danilo Kempf

NETZPLAN 7.2
Durch die recht lineare Ausprägung des Projektes sind nur wenige Pufferzeiten
zu erkenenn. Diese äußern sich in der Vorgangsliste wie folgt:
Nr PSP-Code Vorgang Gesamt- freier
puffer Puffer
1 1 Projekt Schnittstellenmigration/netzintegrierter
Anrufbeantworter durchführen
2 1.1 Analysieren
3 1.1.1 AFP NetStar-Schnittstelle
dokumentieren
4 1.1.2 NetStar-Schnittstellendokumentation
präsentieren
5 1.1.3 TelAPI-Schnittstellendokumentation
präsentieren
6 1.1.4 Softwareanalyse im Testlabor
durchführen
7 1.1.5 Imaginary
Networks-Dokumentation
sichten
0t 0t
0t 0t
15t 15t
8t 8t
6t 6t
8 1.2 Lösung entwerfen
9 1.2.1 Fachkonzept erstellen 0t 0t
10 1.2.2 Brainstorming durchführen 0t 0t
11 1.2.3 Softwarearchitektur definieren 0t 0t
12 1.2.4 Testprotokoll definieren 0t 0t
13 1.3 Softwareentwurf umsetzen
14 1.3.1 implementieren 0t 0t
15 1.3.2 CeBIT-Version erstellen 25t 25t
16 1.3.3 begleitende Funktionstests
durchführen
0t 0t
17 1.3.4 dokumentieren 10t 10t
18 1.4 Testen
19 1.4.1 verifizieren und Defekte beheben 0t 0t
20 1.4.2 analysieren und profilieren,
Probleme beseitigen
2t 2t
21 1.4.3 Dokumentation prüfen 8t 8t
22 1.5 in Betrieb nehmen
23 1.5.1 Installationspaket erstellen 0t 0t
08-045 Kempf Danilo.pdf 59

7 ABLAUF- UND TERMINPLANUNG
24 1.5.2 Abnahme mit Auftraggeber
durchführen
25 1.5.3 Lösung bei der Imaginary
Networks AG in Testbetrieb
nehmen
0t 0t
0t 0t
26 1.6 Projektmanagement durchführen
27 1.6.1 Projektplanung erstellen 0t 0t
28 1.6.2 Meilensteine kontrollieren
29 1.6.2.1 1 – Projektstart 0t 0t
30 1.6.2.2 2 – Projektplanung
abgeschlossen
0t 0t
31 1.6.2.3 3 – Analysephase
abgeschlossen
0t 0t
32 1.6.2.4 4 – Entwurfsphase
abgeschlossen
0t 0t
33 1.6.2.5 5 – CeBIT 2008 25t 0t
34 1.6.2.6 6 – Umsetzungsphase
abgeschlossen
0t 0t
35 1.6.2.7 7 – Testphase abgeschlossen 0t 0t
36 1.6.2.8 8 – Inbetriebnahme
abgeschlossen
0t 0t
37 1.6.2.9 9 – Projekt vollständig
abgeschlossen
0t 0t
38 1.6.3 begleitendes Projektmanagement
durchführen
0t 0t
39 1.6.4 Projektdokumentation erstellen 0t 0t
Für Teilaufgaben sind wiederum keine Pufferzeiten angegeben – dies ist
hier jeweils als 0t zu interpretieren. Die Pufferzeiten für Teilaufgaben ergeben
sich aus den kombinierten Pufferzeiten der enthaltenen Arbeitspakete.
Auffällig bei den Pufferzeiten ist, daß, sofern man vom trügerischen Meilenstein
5 absieht, Gesamt- und freier Puffer stets gleich sind. Auch dies
wird durch den im Wesentlichen linearen Charakter des Projekts erklärt – auf
Vorgänge, die einen Puffer in den Projektablauf einführen folgen niemals weitere
Vorgänge mit freiem Puffer. Somit kann sich in einzelnen Vorgangsketten
kein größerer Gesamtpuffer aufkumulieren.
7.2.3 Terminplanung
Die Ablaufplanung ordnet die Projektvorgänge zeitlich beginnend ab einem
Zeitpunkt 0 an und trägt sie quasi auf einem Zeitstrahl ab. Die Aufgabe der
Terminplanung ist es nun, diese Daten auf den Projektkalender abzubilden
60 Danilo Kempf

ANORDNUNGSBEZIEHUNGEN 7.3
und aus den abstrakten Werten des Netzplans (FAZ, FEZ, etc. . . ) konkrete
Termine zu machen.
Dabei wird zunächst der Projektstarttermin – hier ist dies der 1. November
2007 – dem Zeitpunkt 0 zugeordnet und von dort ausgehend jeder in der
Ablaufplanung einbezogene Tag einem Datum zugeordnet, das im Projektkalender
einen Arbeitstag darstellt. Dies ist manuell recht mühselig und erfolgt
günstigstenfalls mit Tool-Unterstützung. Ich möchte hier darauf verzichten,
eine weitere Vorgangsliste wiederzugeben, die die ermittelten Termine enthält
und verweise stattdessen auf vollständige Vorgangsliste 〈S. 109〉.
Die Netzplantechnik ermittelt für die Projektvorgänge eine früheste und
einen späteste zeitliche Lage. Dementsprechend ergibt auch die Terminplanung
frühest- und spätest mögliche Termine. Die kanonische grafische Darstellung
dafür wäre der vernetzte Balkenplan, auf dessen Wiedergabe ich hier
jedoch ebenfalls verzichten möchte.
Im vorliegenden Projekt besteht eine Besonderheit: Für den Meilenstein
5, also den Beginn der CeBIT 2008, wurde mit Hilfe der Netzplantechnik
ein zeitlicher Puffer von 25 Tagen ermittelt. Dies träfe zu, falls sich die Ce-
BIT nach dem Fortschritt dieses Projekts richtete – innerhalb dieser 25 Tage
wäre ein guter Messezeitpunkt, denn eine Demonstrationsversion der Software
wäre bereits erstellt. In der Realität ist dies natürlich nicht der Fall und
der CeBIT-Beginn ist fix am 4. März 2008. Dies muß in der Terminplanung
natürlich berücksichtigt werden und ändert dann natürlich die Pufferzeiten,
die sich in der Ablaufplanung ergeben haben auf folgende Werte:
Nr PSP-Code Vorgang Gesamt- freier
puffer Puffer
15 1.3.2 CeBIT-Version erstellen 4t 4t
33 1.6.2.5 5 – CeBIT 2008 0t 0t
Wie diese Werte zu Stande kommen, wird in der vollständigen Vorgangsliste
im Anhang vermutlich noch deutlicher.
7.3 Anordnungsbeziehungen
Im vorangegangenen Abschnitt wurde deutlich, daß dieses Projekt – bedingt
dadurch, daß es sich um ein Entwicklungsprojekt handelt – verhältnismäßig
linear ist. Somit besteht zwischen der überwiegenden Zahl der im Projekt
enthaltenen Vorgänge die Anordnungsbeziehung der Normalfolge. Das bedeutet,
daß der größte Teil der Aufgaben begonnen wird, wenn die jeweilige
Vorgänger-Aufgabe abgeschlossen ist. Auch zeitlicher Versatz ist zwischen
den meisten Vorgängen nicht gegeben.
08-045 Kempf Danilo.pdf 61

7 ABLAUF- UND TERMINPLANUNG
7.3.1 Normalfolge
Als Beispiel zur Erläuterung der Normalfolge können die Vorgänge 11 und 12
dienen – ausgedrückt im PSP-Code wären dies die Arbeitspakete 1.2.3 und
1.2.4.
1.2.3 1.2.4
Nr PSP-Code Vorgang Vorgänger Nachfolger
11 1.2.3 Softwarearchitektur
definieren
10 12
12 1.2.4 Testprotokoll definieren 11 32
Das Arbeitspaket 1.2.3 umfaßt das Entwerfen der Softwarearchitektur. Dabei
wird von den beteiligten Entwicklern eine formale Spezifikation erstellt,
die später implementiert wird. Erst nachdem dieses Arbeitspaket abgeschlossen
ist, also erst nachdem diese Spezifikation erstellt ist, kann das folgende
Arbeitspaket beginnen.
Im Arbeitspaket 1.2.4 wird aufbauend auf dieser Spezifikation ein gleichermaßen
formales Testprotokoll definiert, mit dessen Anwendung sich
später – also während und nach der Implementierung – überprüfen lassen
wird, inwiefern sich die tatsächliche Umsetzung an die vorgegebene Spezifikation
hält.
7.3.2 Anfangsfolge
Als Beispiel für die Anfangsfolge bieten sich die Vorgänge 14 und 17 – oder
im PSP-Code 1.3.1 und 1.3.4 – an.
1.3.1
1.3.4
Nr PSP-Code Vorgang Vorgänger Nachfolger
14 1.3.1 implementieren 32 15AF+30t,
16AF+20t,
17AF+20t,
34
17 1.3.4 dokumentieren 14AF+20t 34
62 Danilo Kempf

ANORDNUNGSBEZIEHUNGEN 7.3
Das Arbeitspaket 1.3.1 umfaßt die Umsetzung der entwickelten Softwarespezifikation
in ein auführbares Programm. Grundsätzlich parallel dazu kann
bereits die Erstellung der Dokumentation stattfinden (Arbeitspaket 1.3.4), da
diese grundsätzlich nicht von der Implementierung an sich, sondern nur von
der vorangehend erstellten Spezifikation abhängig ist.
Der zeitliche Versatz bei der Anfangsfolge ergibt sich aus der Tatsache,
daß bei der Implementierung von Softwarespezifikationen recht häufig erkannt
wird, daß die Spezifikation für die Umsetzung nicht eindeutig genug
ist oder kleinere Fehler enthält und somit im Nachhinein noch ergänzt oder
angepaßt werden muß. Diese Anpassungen finden sehr häufig am Anfang des
Implementierungsprozesses statt. Ein zeitlicher Versatz vor Beginn der Dokumentationserstellung
sorgt also hauptsächlich dafür, daß die Dokumentation
gegen eine bereits aktualisierte und relativ wahrscheinlich bereits finale Spezifikation
erstellt wird.
7.3.3 Normalfolge mit zeitlichem Versatz
Während im Projekt auch eine Endfolge auftritt, erscheint als drittes Beispiel
dennoch eine Normalfolge mit zeitlichem Versatz angemessener – konkret
handelt es sich dabei um die Vorgänge 36 und 39, beziehungsweise den Meilenstein
8, der PSP-codiert mit 1.6.2.8 bezeichnet wird und das Arbeitspaket
1.6.4.
1.6.2.8 1.6.4
NF-3t
Nr PSP-Code Vorgang Vorgänger Nachfolger
36 1.6.2.8 8 – Inbetriebnahme
abgeschlossen
39 1.6.4 Projektdokumentation
erstellen
25 39NF-3t
38EF,
36NF-3t
Der Meilenstein 8 markiert grundsätzlich das inhaltliche Ende der Projektdurchführung.
Die entwickelte Softwarelösung ist zu diesem Zeitpunkt
beim Kunden im Testbetrieb. Projektabschließend ist noch die Projektdokumentation
zu erstellen – grundsätzlich kann dies erst nach Abschluß aller inhaltlichen
Vorgänge geschehen.
Die Inbetriebnahme beim Kunden ist jedoch nachgelagerter Projektbestandteil
und kann den Verlauf des Projektes nur relativ gering beeinflussen.
Der inhaltlich komplexere Teil hat bereits in früheren Projektphasen stattge-
08-045 Kempf Danilo.pdf 63
37

7 ABLAUF- UND TERMINPLANUNG
funden. Somit kann die Erstellung der Projektdokumentation schon beginnen,
bevor das Projekt inhaltlich tatsächlich vollständig abgeschlossen ist.
64 Danilo Kempf

Einsatzmittel- und Kostenplanung 8
Nächster Planungsschritt ist die Einsatzmittelplanung. Es werden für die Projektdurchführung
notwendige Ressourcen ermittelt und diese den einzelnen
Projektvorgängen zugeordnet. Durch die Einsatzmittelplanung kann sich
auch die Ablauf- und Terminplanung ändern – beides ist also eng miteinander
verzahnt.
8.1 Einsatzmittelklassen und Einsatzmittelbedarf
Beim vorliegenden Projekt handelt es sich um ein Entwicklungsprojekt. Aus diesem
Grund sind die eingesetzten Ressourcen kaum sachlicher sondern primär
menschlicher Natur.
8.1.1 Mitarbeiterqualifikationen
Da nicht jeder dem Projekt zugewiesene Mitarbeiter gleichermaßen jede Aufgabe
erledigen kann, müssen zunächst die Qualifikationen der einzelnen Mitarbeiter
ermittelt und aufgezeichnet werden. Für den Verlauf des Projektes
werden im Grunde vier verschiedene Qualifikationsebenen oder Rollen benötigt:
Entwickler
Zur Definition des Softwareentwurfes und zur Implementierung werden
Softwareentwickler benötigt.
Da mit diesem Projekt eine Brücken- bzw. Adapterlösung zwischen zwei
Softwareprodukten geschaffen wird, gliedern sich die Entwickler noch
in zwei Teilgruppen. Dies sind:
• Entwickler mit Kenntnissen der Telco-Soft TelAPI-Lösung
• Entwickler mit Kenntnissen der AFP NetStar-Lösung.
technische Mitarbeiter
Technische Mitarbeiter sind an der Analyse der bestehenden Softwarelösungen
beteiligt, führen Tests durch und partizipieren an Qualitätssicherungsmaßnahmen.
Weiterhin sind die technischen Mitarbeiter
für die Einrichtung der Softwarelösung beim Kunden verantwortlich.
Dokumentation
Ein Mitarbeiter ist für die Erstellung der technischen Dokumentation
verantwortlich.
08-045 Kempf Danilo.pdf 65

8 EINSATZMITTEL- UND KOSTENPLANUNG
Projektleiter
Die vierte Rolle im Projekt ist die des Projektleiters.
Die dem Projekt zugeordneten Mitarbeiter lassen sich wie in Abbildung 8.1
gezeigt auf die vier Qualifikationsebenen und ggf. auf ihre Teilebenen abbilden.
8.1.2 Weitere Einsatzmittel
Mitarbeiter Entwickler
TelAPI
NetStar
technischer MA
Dokumentation
Projektleiter
Martin Riedel • •
Thomas Ernemann • •
Michael Walm • •
Sören Schneider • •
Torben Rahlich •
Jens Wippel •
Lothar Karlson •
Jürgen Kurzmann • •
Danilo Kempf • • •
Abbildung 8.1 Mitarbeiterqualifikationen
Über die an der Projektumsetzung beteiligten Mitarbeiter hinaus werden weitere
(sachliche) Einsatzmittel benötigt. Dabei handelt es sich insbesondere
um Telefonieausrüstung, die überwiegend in der Analyse- und Testphase
benötigt wird und die in den weiteren Projektphasen eine eher untergeordnete
Rolle spielt.
Es bedarf dabei unter anderem:
• Teilressourcen einer Telefonanlage zur Schaltung notwendiger Netzwerbindungen
• mehrerer Server zum Ausführen und Analysieren der AFP und Imaginary
Networks-Komponenten
• mehrerer Protokollanalyzer zur Auswertung von Datenverkehr
Auch bei diesen Einsatzmitteln handelt es sich um durchaus knappe
Güter, da sie nur in begrenztem Maße zur Verfügung stehen und in auch in
anderen Projekten sowie in der Linientätigkeit der Telco-Soft GmbH benötigt
werden. Auch diese Einsatzmittel müssen im Zuge der Einsatzmittelplanung
66 Danilo Kempf

EINSATZMITTELKLASSEN UND EINSATZMITTELBEDARF 8.1
in den Projektablauf integriert werden – so ist dies im realen Projektverlauf
auch durchaus geschehen.
Weiterhin existiert eine gewisse Anzahl von Einsatzmitteln, auf deren Planung
in der Praxis verzichtet wurde. So sind beispielsweise Räumlichkeiten
stets in ausreichendem Maße verfügbar – gleiches gilt für Entwickler-
Workstations und Fahrzeuge, die bspw. im Arbeitspaket 1.5.3 Lösung bei
der Imaginary Networks AG in Testbetrieb nehmen benötigt werden.
Um den Umfang dieses Transfernachweises nicht unnötig zu erhöhen, habe
ich auf die weitere Betrachtung der sachlichen Einsatzmittel verzichtet
und gebe im Folgenden nur die sich auf die Mitarbeiter beziehende Einsatzmittelplanung
wieder.
8.1.3 Einsatzmittelverfügbarkeit
Im ersten Schritt der Einsatzmittelplanung wurden die zur Verfügung stehenden
Einsatzmittel aufgezeichet. Für den Projektverlauf ist davon auszugehen,
daß die Mitarbeiter grundsätzlich an jedem Arbeitstag verfügbar sind. Dabei
handelt es sich freilich um eine recht optimistische Herangehensweise, da Linienaufgaben
und andere Projekte ebenfalls einen gewissen Einfluß auf die
Projektbeteiligten ausüben.
In Absprache mit dem Auftraggeber wurde festgelegt, daß die Projektmitarbeiter
nicht mit 100% Einsatz in die Ressourcenplanung einzubeziehen sind,
sondern das als Planungsgrundlage ca. 80% gelten sollen. Die verbleibenden
20% sollen projektexterne Einflüsse, also Linienaufgaben oder weitere Projekte,
abfangen.
Die generellen Arbeitszeiten betragen 40 Stunden pro Woche, Arbeitstage
sind jeweils Montag bis Freitag.
Mitarbeiter Verfügbarkeit
Martin Riedel jeweils 40h/Woche zu 80%
Thomas Ernemann
Michael Walm also Verfügbarkeit für das
Sören Schneider Projekt jeweils 32h/Woche
Torben Rahlich
Jens Wippel
Lothar Karlson
Jürgen Kurzmann
Danilo Kempf 8h/Woche, bei Projektstart und
Projektende bis zu 32h/Woche
08-045 Kempf Danilo.pdf 67

8 EINSATZMITTEL- UND KOSTENPLANUNG
Für die Ressource Entwickler gilt als Besonderheit, daß diese nach Ende der
Implementierungsphase nur noch maximal zu 50% statt 80% in den Projektverlauf
einzubeziehen sind, da hier zu erwarten ist, daß Nachfolgeprojekte
entsprechenden Ressourcenbedarf haben.
8.1.4 Einsatzmittelbedarf
Im nächsten Planungsschritt wird für jeden Projektvorgang der konkrete Einsatzmittelbedarf
ermittelt. Es wird also im konkreten Beispiel für jedes Arbeitspaket
definiert, welche Rollen (bzw. Qualifikationsebenen) in welchem
Umfang beteiligt sein müssen.
Im ersten Schritt führt dies zu einer erweiterten Vorgangsliste:
Nr PSP-Code Vorgang Ressourcenbedarf
1 1 Projekt Schnittstellenmigration/netzintegrierter
Anrufbeantworter durchführen
2 1.1 Analysieren
3 1.1.1 AFP NetStar-Schnittstelle
dokumentieren
4 1.1.2 NetStar-Schnittstellendokumentation
präsentieren
5 1.1.3 TelAPI-Schnittstellendokumentation
präsentieren
6 1.1.4 Softwareanalyse im Testlabor
durchführen
7 1.1.5 Imaginary
Networks-Dokumentation
sichten
2× Entwickler
(NetStar)
4× Entwickler, 1×
Mitarbeiter/Dokumentation
4× Entwickler
3× technischer
Mitarbeiter
2× Entwickler
(TelAPI)
8 1.2 Lösung entwerfen
9 1.2.1 Fachkonzept erstellen 4× Entwickler
10 1.2.2 Brainstorming durchführen 4× Entwickler, 4×
technischer
Mitarbeiter
11 1.2.3 Softwarearchitektur definieren 2× Entwickler
(TelAPI)
12 1.2.4 Testprotokoll definieren 2× Entwickler
(TelAPI), 1×
technischer
Mitarbeiter
68 Danilo Kempf

EINSATZMITTELKLASSEN UND EINSATZMITTELBEDARF 8.1
13 1.3 Softwareentwurf umsetzen
14 1.3.1 implementieren 4× Entwickler
15 1.3.2 CeBIT-Version erstellen 1× Entwickler
16 1.3.3 begleitende Funktionstests 1× technischer
durchführen
Mitarbeiter
17 1.3.4 dokumentieren 1× Mitarbeiter/Dokumentation
18 1.4 Testen
19 1.4.1 verifizieren und Defekte
beheben
20 1.4.2 analysieren und profilieren,
Probleme beseitigen
2× technischer
Mitarbeiter, 3×
Entwickler (zu
25%)
1× technischer
Mitarbeiter, 3×
Entwickler (zu
25%)
21 1.4.3 Dokumentation prüfen 1× Entwickler
(TelAPI)
22 1.5 in Betrieb nehmen
23 1.5.1 Installationspaket erstellen 1× Entwickler
(TelAPI)
24 1.5.2 Abnahme mit Auftraggeber 1× Entwickler, 1×
durchführen
25 1.5.3 Lösung bei der Imaginary
Networks AG in Testbetrieb
nehmen
Projektleiter
2× technischer
Mitarbeiter
26 1.6 Projektmanagement
durchführen
27 1.6.1 Projektplanung erstellen 1× Projektleiter
28 1.6.2 Meilensteine kontrollieren
29 1.6.2.1 1 – Projektstart
30 1.6.2.2 2 – Projektplanung
abgeschlossen
31 1.6.2.3 3 – Analysephase
abgeschlossen
32 1.6.2.4 4 – Entwurfsphase
abgeschlossen
33 1.6.2.5 5 – CeBIT 2008
34 1.6.2.6 6 – Umsetzungsphase
abgeschlossen
35 1.6.2.7 7 – Testphase abgeschlossen
36 1.6.2.8 8 – Inbetriebnahme
abgeschlossen
08-045 Kempf Danilo.pdf 69

8 EINSATZMITTEL- UND KOSTENPLANUNG
37 1.6.2.9 9 – Projekt vollständig
abgeschlossen
38 1.6.3 begleitendes
Projektmanagement
durchführen
39 1.6.4 Projektdokumentation
erstellen
1× Projektleiter
1× Projektleiter
In dieser Vorgangsliste werden jedem Arbeitspaket (analog zu den vorangegangenen
Vorgangslisten werden auch hier die Teilaufgaben und Meilensteine
außer acht gelassen) die Ressourcen zugeordnet. An dieser Stelle
überlappt die Einsatzmittelplanung natürlich erheblich mit der Ablauf- bzw.
Terminplanung. Sind einem Arbeitspaket beispielsweise zwei Entwickler zugeordnet,
ist es theoretisch möglich, dieses Arbeitspaket mit vier Entwicklern
in der halben Zeit durchzuführen.
Dementsprechend ensteht an dieser Stelle ein Regelkreis-Problem: ohne
Ablaufplanung läßt sich die Einsatzmittelplanung nicht vollziehen, deren Resultat
aber wiederum der vollständigen Ablaufplanung voransteht. Letztlich
sind also auch hier die einzelnen Planungsschritte miteinander verzahnt
und können nicht isoliert voneinander betrachtet bzw. durchgeführt werden.
Für weitere Angaben zur Ablaufplanung siehe 7 Ablauf- und Terminplanung
〈S. 51〉.
Kombiniert man den Einsatzmittelbedarf der einzelnen Projektvorgänge
mit den im Zuge der Ablauf- und Terminplanung ermittelten Zeiten ergibt
sich der auf der folgenden Seite wiedergegebene Einsatzmittelplan. Dieser
enthält die durch die Mitarbeiter zu erbringenden Arbeitstage für jede Woche
im Projektverlauf. Zu beachten ist, daß über den Jahreswechsel zweiwöchige
Betriebsferien stattfinden, in denen keine Projektarbeit geleistet wird.
70 Danilo Kempf

Nov Dez Jan Feb Mär Apr
Nr PSP-Code Ressource 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
EINSATZMITTELKLASSEN UND EINSATZMITTELBEDARF 8.1
3 1.1.1 Entwickler (NetStar) 8 8 8 6
4 1.1.2 Entwickler 4
Mitarbeiter/Dokumentation 1
5 1.1.3 Entwickler 4
6 1.1.4 technische Mitarbeiter 12 12 12
7 1.1.5 Entwickler (TelAPI) 4 8 8
9 1.2.1 Entwickler 16
10 1.2.2 Entwickler 16
technische Mitarbeiter 9
11 1.2.3 Entwickler (TelAPI) 8
12 1.2.4 Entwickler (TelAPI) 8
technische Mitarbeiter 4
14 1.3.1 Entwickler 16 16 16 16 16 16 16 16 16 16
15 1.3.2 Entwickler 4
16 1.3.3 technische Mitarbeiter 4 4 4 4 4 4 4 4
17 1.3.4 Mitarbeiter/Dokumentation 4 4 4 4 4
19 1.4.1 technische Mitarbeiter 8 8 4
Entwickler 3 3 3
20 1.4.2 technische Mitarbeiter 4 1
Entwickler 3 3
21 1.4.3 Entwickler (TelAPI) 2
23 1.5.1 Entwickler (TelAPI) 1
24 1.5.2 Entwickler 1
Projektleiter 1
25 1.5.3 technische Mitarbeiter 8
27 1.6.1 Projektleiter 3
28 1.6.3 Projektleiter 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
29 1.6.4 Projektleiter 4
08-045 Kempf Danilo.pdf 71
Abbildung 8.2 Einsatzmittelplan

8 EINSATZMITTEL- UND KOSTENPLANUNG
8.2 Auslastungsprofil für kritische Einsatzmittel
Durch den linearen Charakter des Projekts treten in der Planung kaum Ressourcenüberlastungen
auf. Dies ist insofern erfreulich, als daß dadurch weder
große Änderungen in der Ablaufplanung noch exzessive Maßnahmen der
Einsatzmitteloptimierung notwendig sind. In einem Fall tritt jedoch dennoch
eine Überlastung eines kritischen Einsatzmittels auf:
Das zeitlich umfangreichste Arbeitspaket ist 1.3.1 implementieren, an
dem alle projektbeteiligten Entwickler unter voller Auslastung arbeiten. Dieses
Arbeitspaket umspannt den Meilenstein 5, also die Präsentation einer
Demonstrationsversion zur CeBIT 2008. Dieser Demonstrationsversion
steht allerdings zunächst ihre Erstellung voran, die im Arbeitspaket 1.3.2
CeBIT-Version erstellen kodifiziert ist. Eine grafische Darstellung dieser
Überlastungssituation findet sich in Abbildung 8.3.
8.2.1 Problematik
Im grafischen Auslastungsprofil wird die Problematik dieser Kapazitätsüberlastung
deutlich. Es bestehen mehrere planerische Invarianten,
die im Zuge der Einsatzmitteloptimierung beachtet werden wollen:
CeBIT 2008
Der Messebeginn ist am 4. März 2008. Bis spätestens zu diesem Termin
muß die Demonstrationsversion erstellt sein – d.h. bis zu diesem Termin
muß das Arbeitspaket 1.3.2 (in der Grafik mit B gekennzeichnet)
abgeschlossen sein.
Kapazität
Es arbeiten vier Entwickler am Projekt, die planerisch zu 80% in Projektverlauf
integriert sind. Die maximale Kapazität beträgt also 16 Personentage
pro Woche. Nach Ende der Implementierungsphase sinkt diese
Kapazität auf 50%, also auf 10 Personentage pro Woche, ab.
Diese Kapazitätsabsenkung ist aber (zumindest aus innerprojektlicher
Sicht) durch das Ende der Implementierungsphase bedingt und
nicht andersherum. Verlängerte sich also die Implementierungsphase
stünden auch theoretisch über ihre größere Dauer hinweg mehr Kapazitäten
zur Verfügung. Diese Betrachtungsweise läßt freilich weitere
Projekte der Telco-Soft GmbH außer acht, die in diesem Falle in Verzug
gerieten.
Projektphasen
Die Anordnungsbeziehungen der einzelnen Arbeitspakete über die Projektphasengrenzen
hinweg verbieten die naheliegendste Variante der
Einsatzmitteloptimierung – Arbeitspakete 1.3.1 und 1.4.1 (also in der
Grafik A und C) dürfen sich zeitlich nicht überlappen. Dies würde
schließlich dazu führen, daß mit der Testphase bereits begonnen wird,
72 Danilo Kempf

Auslastung (Personentage)
22
20
18
16
14
12
10
8
6
4
AUSLASTUNGSPROFIL FÜR KRITISCHE EINSATZMITTEL 8.2
Implementierung Test
A
B
2
C
F G
10 12 14 16 18 20 22 24
Zeit (Projektwoche)
Darstellung Bedeutung
A 1.3.1 implementieren
B 1.3.2 CeBIT-Version erstellen
C 1.4.1 verifizieren und Defekte beheben
D 1.4.2 analyisieren und profilieren, Probleme beseitigen
E 1.4.3 Dokumentation prüfen
F 1.5.1 Installationspaket erstellen
G 1.5.2 Abnahme mit Auftraggeber durchführen
Beginn CeBIT 2008 ( 5)
Kapazitätsgrenze
Gesamtpuffer für Arbeitspaket 1.3.2 (B)
Dargestellt wird die Ressource Entwickler in den letzten drei Projektphasen.
Abbildung 8.3 Auslastungsprofil für die Ressource Entwickler
E
D
Inbetriebnahme
08-045 Kempf Danilo.pdf 73

8 EINSATZMITTEL- UND KOSTENPLANUNG
Zeit
während die Implementierungsphase noch nicht abgeschlossen ist. Dies
ist jedoch nicht möglich.
Die Erstellung einer CeBIT-Version will zeitnah vor dem Messebeginn
stattfinden, jedoch dennoch genug Sicherheitsmarge bzw. Pufferzeit aufweisen,
um eventuellen Schwierigkeiten zu begegnen.
Es wird also ersichtlich, daß die geplanten Arbeitspakete in der gewählten
Zeitspanne für das Projektteam nicht zu leisten sind. Es muß also ein Kapazitätsausgleich
stattfinden. Grundsätzlich existieren dabei zwei Varianten –
der kapazitätstreue und der termintreue Kapazitätsausgleich.
8.2.2 kapazitätstreuer Kapazitätsausgleich
Bei dieser Form des Kapazitätsausgleiches bleibt die eingesetzte Einsatzmittelkapazität
gleich. Es werden Arbeitspakete unter Ausnutzung der jeweiligen
Pufferzeiten verschoben und verlagert, so daß es durch diese Form des
Ausgleiches zu einer Terminverschiebung kommt, falls Arbeitspakete des kritisches
Pfades betroffen sind.
Bei einem kapazitätstreuen Ausgleich ist es auch durchaus möglich, zu
evaluieren, welche Arbeitspakete verkürzt oder beschleunigt werden können.
Von einer solchem Maßnahme soll hier jedoch abgesehen werden.
Auslastung (Personentage)
22
20
18
16
14
12
10
8
6
4
Implementierung Test
A
2
B
C
F G
10 12 14 16 18 20 22 24 26
Zeit (Projektwoche)
Abbildung 8.4 kapazitätstreuer Kapazitätsausgleich
E
D
Inbetriebnahme
Im konkreten Projekt wäre ein kapazitätstreuer Ausgleich möglich, wenn
das Erstellen der CeBIT-Version vom Entwicklerteam zeitgleich zur norma-
74 Danilo Kempf

AUSLASTUNGSPROFIL FÜR KRITISCHE EINSATZMITTEL 8.2
len Implementierungsarbeit übernommen würde. Dies wiederum würde das
Ende des Arbeitspaketes 1.3.1 entsprechend herauszögern. Da die Projektphasen
eben nicht überlappen können und die Arbeitspake allesamt auf dem
kritischen Pfad gelegen sind würde sich die Gesamtprojektdauer bei dieser
Lösung um eine Woche verlängern.
8.2.3 termintreuer Kapazitätsausgleich
Dem kapazitätstreuen Kapazitätsausgleich steht der termintreue Kapazitätsausgleich
entgegen. Dabei ist die terminliche Lage im Wesentlichen
unveränderlich und es muß tatsächlich eine Änderung der verfügbaren Kapazitäten
stattfinden.
Im vorliegenden Projekt ist dies relativ einfach möglich. Die Entwickler
sind im Projekt nur zu 80% eingeplant und sind zu 20% in anderen Projekten
bzw. in ihren Linienaufgaben eingebunden. Planerisch kann dieser Spielraum
ausgenutzt werden.
Auslastung (Personentage)
22
20
18
16
14
12
10
8
6
4
Implementierung Test
A
B
2
C
F G
10 12 14 16 18 20 22 24
Zeit (Projektwoche)
Abbildung 8.5 termintreuer Kapazitätsausgleich
E
D
Inbetriebnahme
Diese Anpassung – also die kontrollierte Über- und anschließende Unterschreitung
– der dem Projekt zugewiesenen Ressourcen muß freilich mit dem
Lenkungsausschuß (in hier beschriebenen Umfeld also direkt mit dem Auftraggeber)
projektübergreifend abgestimmt werden.
08-045 Kempf Danilo.pdf 75

8 EINSATZMITTEL- UND KOSTENPLANUNG
8.2.4 gewählte Variante
Im realen Projektverlauf ist der termintreue Kapazitätsausgleich zur Lösung der
beschriebenen Problematik angewandt worden. Dies ist jedoch nicht in der
hier beispielhaft geschilderten Form geschehen. Vielmehr wurde die Entwicklerkapazität
dadurch erhöht, daß ein weiterer, also fünfter, Softwareentwickler
die Erstellung der speziellen Messeversion übernommen hat.
Konkret habe ich selbst diese Aufgabe übernommen und war dementsprechend
am Projekt nicht nur in der Rolle des Projektleiters, sondern auch in
meiner Funktion als einer der Entwickler der Telco-Soft TelAPI-Schnittstelle
beteiligt. Diese im realen Verlauf gewählte Variante ist auch diejenige, die in
der folgenden Kostenplanung geschildert wird.
8.3 Projektkosten
8.3.1 Kostenarten und Kostenstellen
Bei der Kostenplanung für das Projekt werden hier einzig die Kosten für die
projektbeteiligten Mitarbeiter betrachtet. Dies hat zweierlei Gründe:
• Im Rahmen dieses Transfernachweises ist bereits auf die Betrachtung
weiterer Einsatzmittel verzichtet worden. Für die weiteren Einsatzmittel
kann an dieser Stelle also auch keine Kostenplanung durchgeführt
werden.
• Aus dem realen Projektverlauf wird deutlich, daß die Mitarbeiterkosten
die Kosten für weitere Einsatzmittel in erheblichem Maße übersteigen
und den Löwenanteil der Projektkosten ausmachen.
Letzteres gilt für die Entwicklungsprojekte bei der Telco-Soft GmbH gemeinhin.
Aus diesem Grunde werden den Projekten regelmäßig lediglich die
Personalkosten angerechnet – die Kosten für sachliche Einsatzmittel, bei denen
es sich im Allgemeinen um bereits bestehende und ohnehin im Betrieb
befindliche technische Ressourcen handelt, gelten in der Regel als Gemeinkosten.
Auch wenn lediglich die Kosten für die Projektmitarbeiter betrachtet werden,
fallen dennoch je nach Ressource bzw. Rolle unterschiedliche Beträge an:
Ressource Kosten (e pro Personentag)
Entwickler e 600
technischer Mitarbeiter e 400
Mitarbeiter/Dokumentation e 400
Projektleiter e 600
76 Danilo Kempf

8.3.2 Ermittlung der Projektkosten
PROJEKTKOSTEN 8.3
Im vorangegangenen Abschnitt ist jeder Ressource ein Kostensatz pro Einsatztag
zugewiesen worden. Dieser Satz läßt sich nun mit dem Grad der Projektbeteiligung
der einzelnen Mitarbeiter, der Vorgangsdauer und dem Ressourcenbedarf
eines jeden Vorgangs verschneiden. Daraus ergibt sich eine
wiederum erweiterte Vorgangsliste.
Nr PSP-Code Vorgang Kosten
1 1 Projekt Schnittstellenmigration/netzintegrierter
Anrufbeantworter durchführen
2 1.1 Analysieren
3 1.1.1 AFP NetStar-Schnittstelle dokumentieren e 18.000
4 1.1.2 NetStar-Schnittstellendokumentation
präsentieren
e 2.800
5 1.1.3 TelAPI-Schnittstellendokumentation
präsentieren
e 2.400
6 1.1.4 Softwareanalyse im Testlabor durchführen e 14.400
7 1.1.5 Imaginary Networks-Dokumentation sichten e 12.000
8 1.2 Lösung entwerfen
9 1.2.1 Fachkonzept erstellen e 9.600
10 1.2.2 Brainstorming durchführen e 13.200
11 1.2.3 Softwarearchitektur definieren e 4.800
12 1.2.4 Testprotokoll definieren e 6.400
13 1.3 Softwareentwurf umsetzen
14 1.3.1 implementieren e 96.000
15 1.3.2 CeBIT-Version erstellen e 2.400
16 1.3.3 begleitende Funktionstests durchführen e 12.800
17 1.3.4 dokumentieren e 8.000
18 1.4 Testen
19 1.4.1 verifizieren und Defekte beheben e 13.400
20 1.4.2 analysieren und profilieren, Probleme
beseitigen
e 5.600
21 1.4.3 Dokumentation prüfen e 1.200
22 1.5 in Betrieb nehmen
23 1.5.1 Installationspaket erstellen e 600
24 1.5.2 Abnahme mit Auftraggeber durchführen e 1.200
25 1.5.3 Lösung bei der Imaginary Networks AG in
Testbetrieb nehmen
e 3.200
08-045 Kempf Danilo.pdf 77

8 EINSATZMITTEL- UND KOSTENPLANUNG
26 1.6 Projektmanagement durchführen
27 1.6.1 Projektplanung erstellen e 1.800
28 1.6.2 Meilensteine kontrollieren
29 1.6.2.1 1 – Projektstart
30 1.6.2.2 2 – Projektplanung abgeschlossen
31 1.6.2.3 3 – Analysephase abgeschlossen
32 1.6.2.4 4 – Entwurfsphase abgeschlossen
33 1.6.2.5 5 – CeBIT 2008
34 1.6.2.6 6 – Umsetzungsphase abgeschlossen
35 1.6.2.7 7 – Testphase abgeschlossen
36 1.6.2.8 8 – Inbetriebnahme abgeschlossen
37 1.6.2.9 9 – Projekt vollständig abgeschlossen
38 1.6.3 begleitendes Projektmanagement
durchführen
e 12.600
39 1.6.4 Projektdokumentation erstellen e 2.400
Aus dieser Vorgangsliste wird deutlich, daß die über den Projektverlauf
summierten Kosten e 244.800 betragen und damit das Projektbudget knapp
unterschreiten.
8.3.3 Kostengang- und Kostensummenlinie
Im vorgangegangenen Abschnitt sind die Kosten pro Arbeitspaket errechnet
worden. Ebenso interessant sind aber auch die Kosten pro Projektwoche, also
eine Darstellung des zeitlichen Kostenverlaufs.
Kosten (× e 1.000)
16
14
12
10
8
6
4
2
0
Nov Dez Jan Feb Mär Apr
0 4 8 12 16 20 24
Betriebsferien
Projektwoche
Abbildung 8.6 Kostenganglinie
78 Danilo Kempf

PROJEKTKOSTEN 8.3
Die Kosten pro Projektwoche, die in der Kostenganglinie in Abbildung 8.6
dargestellt sind, lassen sich leicht aus der in Abbildung 8.2 aufgezeichneten
Einsatzmittelplanung errechnen. Letztlich müssen hier einfach die pro Projektwoche
anfallenden Kosten für jedes Arbeitspaket aufsummiert werden.
Numerisch betragen die Kosten pro Projektwoche:
Projektwoche Kosten Summe Bemerkungen
1 e 16.200 e 16.200 Planungsphase, Beginn Analysephase
2 e 15.000 e 31.200
3 e 15.000 e 46.200
4 e 7.000 e 53.200
5 e 10.200 e 63.400 Beginn Entwurfsphase
6 e 13.800 e 77.200
7 e 5.400 e 82.600
8 e 7.000 e 89.600
9 – e 89.600 Betriebsferien
10 – e 89.600 . . . dito. . .
11 e 10.200 e 99.800 Beginn Implementierungsphase
12 e 10.200 e 110.000
13 e 11.800 e 121.800
14 e 13.400 e 135.200
15 e 13.400 e 148.600
16 e 13.400 e 162.000
17 e 15.800 e 177.800
18 e 13.400 e 191.200 Beginn CeBIT 2008
19 e 11.800 e 203.000
20 e 11.800 e 214.800
21 e 5.600 e 220.400 Beginn Testphase
22 e 10.200 e 230.600
23 e 6.200 e 236.800
24 e 1.200 e 238.000
25 e 6.800 e 244.800 Inbetriebnahme, Abschlußphase
Neben den Kosten pro Projektwoche ist in der Tabelle auch die Summe
der bis zur jeweiligen Projektwoche anfallenden Kosten angegeben. Der aus
dieser Aufsummierung entstehende Graph ist als Kostensummenlinie in Abbildung
8.7 wiedergegeben.
08-045 Kempf Danilo.pdf 79

8 EINSATZMITTEL- UND KOSTENPLANUNG
Kosten (× e 10.000)
25
20
15
10
5
Betriebsferien
0
Nov Dez Jan Feb Mär Apr
0 4 8 12 16 20 24
Projektwoche
Abbildung 8.7 Kostensummenlinie
Mit geringem Aufwand lassen sich aus diesen Zahlen die Kosten pro Projektphase
ermitteln:
Projektphase Kosten
Planungsphase e 1.800
Analysephase e 51.400
Entwurfsphase e 36.400
Implementierungsphase e 125.200
Testphase e 23.200
Abschlußphase e 6.800
Überraschend für mich ist hier, daß die Kosten der Analysephase die der
Entwurfsphase übersteigen, dies ist im Vergleich zu vergangenen Projekten
der Telco-Soft GmbH eher unüblich. Ich denke, daß sich diese Anomalie damit
erklären läßt, das im vorliegenden Projekt die technische Basis (Imaginary
Networks-Software, AFP NetStar-Schnittstelle) vergleichsweise unbekannt
war und aus diesem Grund eine äußerst umfangreiche Analysphase stattfinden
mußte.
80 Danilo Kempf

Soziale Kompetenz 9
Durch die recht speziellen Bedingungen dieses Projektes kann den sozialen
Aspekten im Projektablauf eine besondere Bedeutung beigemessen werden.
Dies sind im Einzelnen:
• Konkurs der AFP GmbH
• Übernahme des AFP NetStar-Quellcodes durch die Telco-Soft GmbH
• Integration zweier ehemaliger AFP-Mitarbeiter in das Team der Telco-
Soft GmbH
• Integration einiger NetStar-Komponenten in die Telco-Soft TelAPI
Diese Fakten, die unterschiedliche Unternehmenskultur der AFP GmbH
und der Telco-Soft GmbH, die neue Teamsituation und das erhöhte Konfliktpotential
machen gesteigerte Aufmerksamkeit auf Teamentwicklungsprozesse
erforderlich.
9.1 Teamarbeit (Teambildung und Konflikte)
Die Telco-Soft GmbH ist ein recht kleines Unternehmen mit etwa 30 Mitarbeitern.
Diese geringe Größe, die entspannte und wenig formale Art der internen
Kommunikation und Zusammenarbeit sowie ein gut entwickeltes Gemeinschaftsgefühl
haben dafür gesorgt, daß sich unternehmensweit ein großes, an
einem Strang ziehendes, wenngleich nicht immer konfliktfreies Team gebildet
hat.
Durch die Art der Unternehmensorganisation (siehe 4.2.1 Stammorganisation
〈S. 33〉) bedingt bilden sich für Projekte und Linienaufgaben regelmäßig
kleine, fokusierte Teams mit gut geklärten Verantwortlichkeiten. Letzlich
kennen sich alle Mitarbeiter gegenseitig recht gut und stellen füreinander
öffentliche Personen dar. Somit sind im üblichen Arbeitsablauf die Teamentwicklungsprozesse
recht positiv zu bewerten.
Dies hat sich durch die Einstellung der beiden ehemaligen Mitarbeiter der
AFP GmbH natürlich geändert – durch Änderungen an der Teamkonfiguration
beginnt erneut eine Orientierungsphase. Eine positiv verlaufende Integration
der neuen Mitarbeiter nicht nur in das Projektteam sondern in das Unternehmen
als Ganzes ist auch eines der Ergebnisziele dieses Projektes.
08-045 Kempf Danilo.pdf 81

9 SOZIALE KOMPETENZ
9.1.1 Johari-Fenster
Bevor auf die Teamentwicklung beeinflussend eingewirkt werden kann, sollte
zunächst evaluiert werden, wie die einzelnen Teammitglieder einander
wahrnehmen. Dies sollte eher durch Beobachtung als durch Befragung geschehen.
Die Klassifizierung solcher Wahrnehmungen kann im sogenannten
Johari-Fenster erfolgen.
anderen unbekannt
dem Selbst bekannt dem Selbst unbekannt
anderen bekannt freie Aktivität blinder Fleck
Vermeiden/Verbergen unbekannte Aktivität
Rot eingezeichnet ist die durch Maßnahmen zur Förderung der Teamentwicklung indendierte
Größenzunahme des Bereichs freie Aktivität.
Abbildung 9.1 Johari-Fenster
Das Johari-Fenster unterteilt sich in vier Bereiche:
freie Aktivität
Verhaltensweisen, Beweggründe, Motive, Charakterzüge sind dem
Teammitglied selbst und sowie den anderen Teammitgliedern bekannt.
Diese bekannten Eigenschaften sind also öffentlich, können gemeinsam
diskutiert und in Entscheidungsfindungsprozesse einbezogen werden.
Maximierung dieses Bereiches sollte Ziel der Teamentwicklungsprozesse
sein.
blinder Fleck
Bestimmte Verhaltensweisen eines Teammitglieds sind ihm selbst nicht
bekannt, anderen Mitarbeitern sehr wohl. Dies kann sich, insbesondere
bei negativen Aspekten, rasch zum Problem entwickeln, weil so zwischen
Teammitgliedern schnell unausgesprochene Konfliktsituationen
entstehen können. Dieser Bereich sollte also minimiert werden.
Vermeiden/Verbergen
Dieser Bereich des Johari-Fensters stellt den privaten bzw. geheimen Bereich
eines Teammitglieds dar – insbesondere also Schwächen, die das
Teammitglied selbst kennt, dem Team aber nicht preisgeben möchte.
82 Danilo Kempf

TEAMARBEIT (TEAMBILDUNG UND KONFLIKTE) 9.1
Auch hier sollte darauf hingearbeitet werden, diesen Bereich zu minimieren.
Dies ist allerdings recht schwierig und gelingt nur bei sehr erfolgreichen
Teambildungsmaßnahmen.
unbekannt
Dieser Bereich stellt Verhaltensweisen oder Motive dar, die weder das
Teammitglied selbst, noch das Team wahrnehmen. Alle Verhaltensweisen
in diesem Bereich des Johari-Fensters üben also tatsächlich eine Wirkung
aus, werden aber nicht als solche wahrgenommen.
Naturgemäß sollte auch dieser Bereich minimiert werden. In der Praxis
wird dies jedoch kaum möglich sein.
Fände das vorliegende Projekt ohne die beiden neuen Mitarbeiter statt,
wäre bereits bei Beginn ein sehr großer Bereich der freien Aktivität gegeben –
die Teammitglieder sind miteinander sehr gut bekannt und arbeiten auch in
der Linientätigkeit eng zusammen.
Durch die neuen Mitarbeiter beginnt das Projekt und die Teamentwicklung
natürlich mit deutlich größeren Bereichen des Blinden Flecks und des Vemeidens
und Verbergens insbesondere Seitens der neuen Mitarbeiter. Dies zu
Ändern ist eines des Projektziele.
9.1.2 Teamentwicklung
Zur Darstellung von Teamentwicklungsprozessen wird häufig die Teamuhr
nach B. W. Tuckman herangezogen, die die Teamentwicklung in fünf Phasen
darstellt:
Forming
Dies ist die Kennenlernphase, in der die Mitarbeiter sich in der Regel
eher zurückhaltend beschnuppern. Während der Umgangston hier
freundlich ist, kann produktive Arbeit kaum stattfinden.
Storming
Dies ist die Machtkampf- oder Konfliktphase, in der um informelle
Führungspositionen im Team gerungen wird. In dieser Phase sind die
Teammitglieder eher Ich- als Wir-orientiert.
Norming
Auf diese Phase folgt die Organisationsphase. Die Konflikte der
Storming-Phase werden aus dem Wege geräumt, es entsteht ein Austausch
zwischen den Teammitgliedern. Das Team beginnt zu funktionieren
und ist Wir-orientiert.
Performing
In dieser Leistungs- oder Wirkphase hat sich eine starke und ergebnisorientierte
Teamarbeit entwickelt. Zwischen den Teammitgliedern
herrscht Solidarität und Offenheit. Schnelles Erreichen dieser Entwicklungsphase
muß Ziel der Führungsarbeit sein – es ist aber nicht selbstverständlich,
daß diese Phase überhaupt erreicht wird.
08-045 Kempf Danilo.pdf 83

9 SOZIALE KOMPETENZ
Adjourning
Dies ist die Teamauflösungsphase am Ende des Projektes. Diese Phase
soll und wird es im vorliegenden Projekt nicht geben Durch die Einflußorganisation
verbleibt das Team auch während der Projektarbeit in den
Linienstrukturen, so wirkt sich die Teamentwicklung innerhalb des Projekts
auch direkt auf die Linienarbeit aus – eine Auflösung des Teams
findet schlicht nicht statt.
Im tatsächlichen Projektverlauf waren die ersten vier dieser fünf Phasen
tatsächlich erkennbar. Als Projektleiter habe ich versucht, positiv steuernd
einzuwirken.
Forming
Die beiden ehemaligen Mitarbeiter der AFP GmbH haben ihre Arbeit bei
der Telco-Soft GmbH nicht zeitgleich mit dem Projektbeginn, sondern
bereits einen Monat zuvor – also zum 1. Oktober 2007 – angetreten. In
dieser Zeit haben sie sich im Wesentlichen im Unternehmen orientiert,
sich mit den anderen Mitarbeitern bekannt gemacht und kleinere Pflegearbeiten
am von Telco-Soft erworbenen AFP-Quelltext durchgeführt. Eine
konkrete Zusammenarbeit mit anderen Mitarbeitern ist jedoch noch
nicht erfolgt.
Dieser initiale Monat stellt bereits einen großen Teil der Forming-Phase
dar, die somit nicht erst mit dem Projektstart beginnt, sich aber über die
ersten Projekttage hin fortstetzt.
Bezogen auf das Projekt formiert sich das Team insbesondere zu Beginn
der Analysephase. Die beiden ehemaligen AFP-Mitarbeiter erstellen im
Wesentlichen gemeinsam die Dokumentation zur NetStar-Schnittstelle,
arbeiten also sicher in einem gewohnten Team.
Mit den neuen Kollegen ergeben sich während dieser Phase zunächst
nur wenige den Projektablauf betreffende Schnittstellen. Insbesondere
ist dies die Präsentation der Telco-Soft-Schnittstelle, also eine erste
Einführung in das Produkt an dem die neuen Mitarbeiter von nun an
beteiligt sein werden.
Die bestehenden Mitarbeiter waren gehalten, auf die neuen Mitarbeiter
zuzugehen und zumindest informierend in eigene Aufgaben mit einzubeziehen
(Vostellung des Testlabors, Erläutern der eigenen Aufgaben,
etc. . . ).
84 Danilo Kempf

Storming
Norming
TEAMARBEIT (TEAMBILDUNG UND KONFLIKTE) 9.1
Im Projektablauf zeigte sich tatsächlich relativ schnell der Beginn der
Storming-Phase. Grundsätzlich hatten ja die Entwickler der Telco-Soft
GmbH und die Entwickler der AFP GmbH an unmittelbaren Konkurrenzprodukten
gearbeitet. So zeigte sich, daß sich in den gemeinsamen
Arbeitspausen oder nach Feierabend relativ rasch Diskussionen über
das Für- und Wider bestimmter technischer Lösungsansätze entwickelten.
Meine Aufgabe als Projektleiter war es hier, durch vorsichtige Einflußnahme
ein Eskalieren der Situation zu verhindern, letztlich sind beide
Gruppen, also Telco-Soft- wie AFP-Entwickler, ja davon überzeugt, die
technisch bessere Lösung geschaffen zu haben.
Grundsätzlich sehe ich eine – auch durchaus umfangreiche – Storming-
Phase jedoch als nicht unbedingt schlecht an. Durch das Austragen
und Ausdiskutieren kleinerer Konflikte vergrößert sich schließlich im
Johari-Fenster der Bereich der freien Aktivität, die Teammitglieder werden
füreinander also durchschau- und einschätzbarer.
Ein klares Ende der Storming-Phase konnte ich im Projektablauf nicht
erkennen, sie ging relativ nahtlos in die folgende Norming-Phase über.
Ein solcher fließender Übergang mag der Grund dafür sein, daß diese
beiden Phasen im 4-Phasen-Modell der Teamentwicklung zu einer Phase
(nämlich Gärung/Klärung) zusammengefaßt sind.
Einen klaren Beginn der Norming-Phase kann ich im Projektablauf nicht
ausmachen. Im Verlauf der Entwurfsphase ging sie aus der Storming-Phase
hervor.
Um diese Norming-Phase zu forcieren habe ich in die Projektplanung
das Arbeitspaket 1.2.2 Brainstorming durchführen aufgenommen. In
diesem Arbeitspaket werden Entwickler und technische Projektmitarbeiter
an einen Tisch gesetzt und diskutieren über eine sinnvolle Softwarearchitektur.
Dabei ist das Fachkonzept jedoch bereits von den TelAPI-
Entwicklern erstellt, ein enges Gerüst ist also bereits vorgegeben.
Ich habe mit einer geplanten Dauer von 3 Tagen dieses Arbeitspaket
recht lang angesetzt, um dem relativ neu gebildeten Team ausreichend
Zeit zur Konsensfindung zu geben, so das Entscheidungen eben vom
ganzen Team getragen werden.
08-045 Kempf Danilo.pdf 85

9 SOZIALE KOMPETENZ
Performing
Adjourning
In der Praxis zeigte sich, daß die Norming-Phase sehr lang andauerte
und Konflikte immer wieder auftraten, also auch Elemente der
Storming-Phase relativ spät im Projekt zu erkennen waren. Ich mache
dafür zum einen die für die ehemaligen AFP-Mitarbeiter unglückliche
Aufgabenstellung und die erheblich unterschiedliche Unternehmenskultur
verantwortlich. Bei der Telco-Soft GmbH herrscht ein relativ
lockerer Umgangston, aber ein sehr formaler Entwicklungsprozeß – dies
scheint mir persönlich bei der AFP GmbH genau entgegengesetzt der
Fall gewesen zu sein.
Ich habe auf das Team hier relativ wenig Einfluß genommen und nur
die Ziele aufgezeigt. Letztlich war es mir wichtiger, daß die Norming-
Phase von selbständig abläuft und sich eine natürliche Teamordnung
bildet, als Teamregeln anzuordnen. Dies ist meines Erachtens für die
Projekt- bzw. Teamkultur erheblich von Vorteil, auch wenn dies eine
längere Norming-Phase impliziert.
Für mich waren gegen Projektende Anzeichen der Leistungsphase erkennbar
– letztlich geht auch diese verhältnismäßig nahtlos aus der
Norming-Phase hervor. Es zeigte sich, daß die Teammitglieder gegen
Ende alle an einem Strang zogen, wobei nicht nur die ehemaligen
AFP-Mitarbeiter den erforderlichen Schritt in Richtung Telco-Soft-
Unternehmenskultur gemacht haben, sondern erfreulicherweise auch
ein Schritt in die Gegenrichtung erfolgt ist.
Nach Projektende sollen die neuen Mitarbeiter Aufgaben in der TelAPI-
Entwicklung übernehmen – die grundsätzliche Teamstruktur bleibt also
bestehen. Es wird sich nach Projektende zeigen, ob tatsächlich eine Performing-Phase
in der Teamentwicklung erreicht werden konnte.
Da, wie erwähnt, nach Projektende die grundlegende Teamstruktur für
die Linientätigkeit erhalten bleibt, gibt es im vorliegenden Fall keine
Adjourning-Phase der Teamentwicklung.
Aufgabe des Projektleiters ist es letztendlich, die Teambildung durch angemessene
formelle und informelle Maßnahmen zu unterstützen. Im Einzelnen
teilt sich diese Aufgabe in folgende Komponenten:
• Spielregeln schaffen und den Teammitgliedern vermitteln
86 Danilo Kempf

FÜHRUNG (FÜHRUNGSSTILE UND ENTSCHEIDUNGSFINDUNG) 9.2
• Zuständigkeiten zuweisen, auf deren Einhaltung achten
• Konflikte erkennen und Lösen
• Vermitteln, bei Entscheidungsfindung auf Teamkonsens achten
9.2 Führung (Führungsstile und Entscheidungsfindung)
Auch als Projektleiter nehme ich im konkreten Projekt keine wirkliche
Führungsrolle ein. Dies hat zweierlei Gründe:
• Die geringe Unternehmensgröße und flache Hierarchieebenen.
• Die Wahl der Einflußorganisation.
Letzten Endes obliegt mir als Projektleiter eher die Rolle als Schnittstelle
zwischen Projektmitarbeiter und Auftraggeber. Die Führungsaufgaben
und Entscheidungskompetenzen verbleiben beim Auftraggeber, jedoch kann
ich als Projektleiter natürlich beeinflussend eingreifen. Meines Erachtens
stellt diese Herangehensweise schon die Anwendung des Management-by-
Objectives-Prinzipes dar, schließlich werden zwischen Führungsperson und
Mitarbeiter gemeinsam Ziele ermittelt und vereinbart, die dann umgesetzt
werden.
Dieser Ansatz wird von mir natürlich in das Projekt weiter transportiert
– wenn alle Mitarbeiter an der Zielfindung beteiligt sind und die jeweiligen
Ziele auch von sich aus tragen, scheint mir ein wesentlich motivierteres und
angenehmeres Arbeiten möglich.
Ein solches Management-by-Objectives ist nur im kooperativen Führungsstil
möglich. Grundsätzlich werden die Vorgaben im Groben gemeinsam ermittelt
– für Detailfragen herrscht jeder großer Entscheidungsspielraum bei den einzelnen
Mitarbeitern. Natürlich muß darauf geachtet werden, daß das Team
niemals vollständig sich selbst überlassen bleibt – die kooperative Führung
aus Zeitmangel oder Unachtsamkeit in den laissez-faire-Bereich abgleitet, der
letztlich zu Chaos führen würde.
Natürlich ist der Grad der Einflußnahme im Führungsprozeß nicht immer
gleich. Bei Projektbeginn wird hier den einzelnen Mitarbeitern relativ wenig
Entscheidungsspielraum zugestanden – die Projektidee und die Projektziele
wurden vorab entwickelt und sind relativ unbeweglich und festgelegt.
Im Gegensatz dazu haben die Mitarbeiter in der Entwurfsphase nahezu
uneingeschränkten Handlungs- und Entscheidungsspielraum, der durch
praktisch keine Einflußnahme von außen in vorgegebene Richtungen gelenkt
wird. Dies ist natürlich durch den Projektcharakter bedingt, es handelt sich
eben um ein Entwicklungsprojekt, in dem etwas Neues geschaffen wird. Die
Entwicklung von Lösungen ist immer ein kreativer Prozeß, der so wenig wie
möglich beeinflußt werden sollte.
08-045 Kempf Danilo.pdf 87

9 SOZIALE KOMPETENZ
In der Implementierungsphase muß wiederum mehr Steuerungsfunktion
ausgeübt werden – beim Implementieren ist tatsächlich auch von den
Mitarbeitern weniger Kreativität gefragt, hier ist eher Regelkonformität positiv
zu bewerten. Diese Regelkonformität ist ein Faktor, der für eine erfolreiche
Qualitätssicherung absolut erforderlich ist. Dies geht so weit, als daß in
vielen Software-Entwicklungsprojekten hier tatsächlich außerordentlich autoritär
und geradezu bürokratisch geführt wird.
Dies ist im vorliegenden Projekt nicht unbedingt der Fall. Aus Sicht des
Auftraggebers wird weiterhin sehr kooperativ geführt. Die Einhaltung vorgegebener
Prozesse wird vom Team in seiner Gesamtheit selbst überwacht und
sichergestellt. In der Praxis ist dies noch nicht passiert – ich gehe jedoch davon
aus, daß, sollten die definierten Entwicklungsprozesse nicht eingehalten
werden, der Auftraggeber dies schlimmstenfalls auch autoritär sicherstellen
würde. Letztlich ist es auch hier keine Schwarz-Weiß-Lösung, die Anwendung
findet – grundsätzlich wird der Situation angemessen geführt. Diese
sinnvolle Kombination der Führungsstile wird als situative Führung bezeichnet
und erscheint mir persönlich als flexibelster und in der Realität angebrachtester
Ansatz zur Führung.
9.3 Kommunikation im Projekt (Meetings, Berichte, Beteiligungen)
Ohne tatsächliche Führungskompetenz bleibt – neben den planerischen
Aspekten – meine Hauptaufgabe im Projekt die der Kommunikation. Als Projektleiter
bilde ich die Schnittstelle zwischen Auftraggeber, Projektteam und
Kunden. Die stattfindenden Kommunikationsmaßnahmen sind im Abschnitt
2.3 Stakeholderportfolio und Stakeholdersteuerung 〈S. 19〉 in Form einer Kommunikationsmatrix
aufgezeichnet. Diese Kommunikationsmaßnahmen werden
von mir wahrgenommen. Im Einzelnen sind dies:
Pflege des Projektkalenders
Alle am Projekt beteiligten Mitarbeiter haben Zugriff auf einen internen
Projektkalender, der sie über stattfindende Vorgänge, Fortschritte, Zeitverzüge
informiert. Mir als Projektleiter obliegt natürlich schon aus planerischer
Hinsicht die Pflege dieses Kalenders, der aber zeitgleich auch
ein wichtiges Kommunikationsinstrument darstellt.
Statusupdates
Im Schnitt alle drei Arbeitstage wird, basierend auf den kurzen
Fortschritts- oder Problemberichten der Projektmitarbeiter und unter
Auswertung von im direkten Gespräch erhaltenen Informationen von
mir ein kurzer Statusbericht verfaßt und schriftlich an die Projektmitarbeiter
verteilt. Dieses Kommunikationsmittel dient vordringlich dazu,
Mißverständnissen, die durch unklare oder sachlich falsche Berichte
oder durch Fehlinterpretation von informell überlieferte Information
vorzubeugen und allen Beteiligten einen klaren Stand zu vermitteln.
88 Danilo Kempf

KOMMUNIKATION IM PROJEKT (MEETINGS, BERICHTE, BETEILIGUNGEN) 9.3
Diese Statusupdates müssen durch die Mitarbeiter nicht bestätigt werden,
sollen aber, enthalten sie falsche Informationen, korrigiert werden.
Damit dienen sie als Basis und als Informationsquelle für die Berichte
an den Auftraggeber.
Berichte an den Auftraggeber
In von der Projektphase abhängiger Häufigkeit bereite ich den Projektfortschritt
in schriftlicher Form für den Auftraggeber auf. Dafür existiert
hausintern ein Berichtstemplate, das nur stichpunktartig auszufüllen ist.
In den Analyse- und Entwurfsphasen werden keine solchen Berichte
verfaßt, lediglich wenn Probleme auftreten werden diese in Berichtsform
dokumentiert. Der Grund dafür ist, daß in diesen Phasen der Fortschrittsgrad
eher schlecht meßbar ist. Dafür werden während Implementierung
und Test einmal wöchentlich Berichte erstellt, die den Fortschrittsgrad
genau wiedergeben.
Updates für Kunden
Beginnend mit der Implementierungsphase wird einmal wöchentlich
von mir ein schriftliches Update an die Imaginary Networks AG versandt,
daß den Projektfortschritt detailliert wiedergibt.
Updates für weitere Mitarbeiter
Sporadisch pflege ich die Projektseiten im Intranet, so daß die weiteren
Mitarbeiter der Telco-Soft GmbH über den Projektfortgang informiert
bleiben.
Besprechungen
Unternehmensweit findet einmal die Woche eine verhältnismäßig kurze
Lagebesprechung statt. Die Teilnahme ist generell für jeden Mitarbeiter
freiwillig. Es hat sich hier eingebürgert, daß je nach Projekt und Arbeitsauslastzung
jeweils ein oder zwei Projektmitarbeiter an dieser Besprechung
teilnehmen. Sie dient dazu unternehmensweit zu kommunizieren
und den Fortschritt anderer Projekte oder Linienaufgaben nicht aus
den Augen zu verlieren.
Zusätzlich zu diesen formellen Kommunikationsmaßnahmen besteht eine
weitere Ebene, nämlich die der informellen Kommunikation. Durch Gespräche
mit und zwischen Projektmitarbeitern findet ein Informationsaustausch
statt, der die sachliche bzw. fachliche Ebene auch verlassen kann und
zur – auch privaten – Alltagskommunikation dient. Als Projektleiter ist es
wichtig, auch an diesem persönlichen Informationsaustausch teilzunehmen,
dies gilt insbesondere, als das ich in meiner Linientätigkeit ja Teil des Entwicklerteams
bin.
08-045 Kempf Danilo.pdf 89

Wahlelemente 10
Für diesen Abschnitt des Transfernachweises waren drei Wahlelemente zu bearbeiten.
Ich habe mich für die folgenden Elemente entschieden:
• Konfiguration und Änderungen
• Projektstart und Projektende
• Projektberichtswesen und Projektdokumentation
Die Nummerierung der folgenden Abschnitte entspricht der Nummerierung,
die durch die Anleitung zum Transfernachweis vorgegeben wird.
10.6 Konfiguration und Änderungen
Konfigurations- und Änderungsmanagement sind miteinander verbundene
Prozesse, die nicht losgelöst voneinander betrachtet werden können. Sie sind
in den folgenden beiden Abschnitten näher erläutert.
10.6.1 Konfigurationsmanagement
Die funktionellen und physischen Merkmale der Projektleistung, also hier der
zu entwickelnden Adapterlösung, werden als Konfiguration bezeichnet. Eine
Konfiguration stellt also eine dokumentierte Sammlung aller Anforderungen
an das Produkt beziehungsweise an die Leistung dar.
Aufgabe des Konfigurationsmanagements ist es nun, durch kontinuierliches
Dokumentieren Transparenz bezüglich der Konfiguration herzustellen.
Es werden nicht nur die Anforderungen, sondern auch der Grad ihrer
Erfüllung dokumentiert. Damit ist das Konfigurationsmanagement eng mit
dem Dokumenten- sowie mit dem Änderungsmanagement verknüpft.
Konfigurationsmanagement gliedert sich in vier Teilaufgaben:
Konfigurationsidentifizierung
Dieser erste Handlungsschritt umfaßt daß Benennen von Konfigurationseinheiten
und das Definieren ihrer Eigenschaften.
Konfigurationsüberwachung
ist die Schnittstelle des Konfigurations- und Änderungsmanagement
und befaßt sich mit dem durch die Genehmigung von Änderungsanträgen
entstehenden Wandel in der Projektkonfiguration.
08-045 Kempf Danilo.pdf 91

10 WAHLELEMENTE
Konfigurationsbuchführung
ist die Schnittstelle zum Dokumentenmanagement und bezeichnet
das rückverfolgbare Dokumentieren der Konfiguration und ggf. ihrer
Änderungen.
Konfigurationsaudit
beschreibt das Prüfen des Produktes darauf, ob es alle im Identifizierungsschritt
ermittelten und im Buchführungsschritt dokumentierten
Merkmale aufweist bzw. alle Anforderungen erfüllt.
Im konkreten Projekt existiert kein explizites Konfigurationsmanagement,
es werden die enstprechenden Aufgaben also nicht ausdrücklich Projektmitarbeitern
zugewiesen. Ich verwalte die erstellten Dokumente in meiner Rolle
als Projektleiter.
Die Aufgaben des Konfigurationsmanagement finden im Projekt implizit
statt:
Konfigurationsidentifizierung
Die Konfigurationsidentifizierung findet in Teilen vor Projektbeginn
(siehe Projektstartsitzung im Abschnitt 10.7.1 Projektstart 〈S. 95〉) und in
Teilen im Arbeitspaket 1.2.1 Fachkonzept erstellen statt. Ergebnis dieses
Arbeitspaketes ist das Fach- oder Datenverarbeitungskonzept, das einem
Pflichtenheft entspricht.
Granulierter wird im Arbeitspaket 1.2.3 Softwarearchitektur definieren
eine technische Spezifikation definiert, die ebenfalls Teil der Konfiguration
ist.
Konfigurationsüberwachung
Siehe 10.6.2 Änderungsmanagement 〈S. 93〉.
Konfigurationsbuchführung
Die Konfigurationsbuchführung ist aufgrund der geringen Projektgröße
mit der Konfigurationsidentifizierung verschmolzen. Während das Verwalten
der erstellten Dokumente mir als Projektleiter zukommt, besteht
kein umfangreiches Dokumentenmanagement. Auf Werkzeuge wie eine
Dokumentenbedarfsmatrix oder auf komplexe Kennzeichnungsschemata
wird im vorliegenden Projekt verzichtet.
Neben den projektplanerisch relevanten Dokumenten (Projektstrukturplan,
Arbeitspaket-Beschreibungen, etc. . . ) werden im Projektverlauf
nur wenige Dokumente produziert. Diese sind:
• Schnittstellendokumentation der AFP NetStar-Schnittstelle
• Fachkonzept (Pflichtenheft)
• Softwarearchitektur (UML-Diagramme)
• Programmdokumentation
• Testprotokolle
Konfigurationsaudit
Der Konfigurationsaudit gliedert sich in mehrere Teile. Zunächst wird
92 Danilo Kempf

KONFIGURATION UND ÄNDERUNGEN 10.6
in der Testphase (Teilaufgabe 1.4 sowie untergeordnete Arbeitspakete),
ob die entwickelte Lösung den festgelegten Kriterien entspricht. Ein
weiterer Audit findet im Arbeitspaket 1.5.2 Abnahme mit Auftraggeber
durchführen statt.
10.6.2 Änderungsmanagement
Das Änderungsmanagement beschreibt die Abläufe in einem Unternehmen oder
einem Projekt, die zum Zweck existieren, Änderungen an Produkten oder an
der Organisation sowohl kontrolliert als auch insbesondere dokumentiert vorzunehmen.
Insbesondere in einem Entwicklungsprojekt kommt dem Änderungsmanagement
eine besondere Bedeutung zu. Jede Abweichung vom vorher
festgelegten Plan muß dazu in Form eines schriftlichen Änderungsantrages aufgenommen
werden. Für jeden Änderungsantrag findet dann eine umfangreiche
Analyse statt, die mindestens folgende Schritte umfaßt:
• Der Grund oder Anlaß der Änderung muß identifiziert werden.
• Anschließend wird beschrieben, was durch den Änderungsantrag wie
geändert werden soll.
• Es wird planerisch festgestellt, welche weiteren Änderungen sich durch
Umsetzung des Änderungsantrages ergeben würden.
• Daraufhin wird Kosten und Nutzen der Änderung bzw. deren Nichtdurchführung
bewertet und es wird über Genehmigung oder Ablehnung
des Änderungsantrages entschieden.
• Ist der Änderungsantrag genehmigt, wird die Änderung durchgeführt.
• Es wird überprüft, ob der durch den Änderungsantrag angepeilte Nutzeffekt
tatsächlich eingetreten ist.
Grafisch ist dieser Änderungsprozeß in Abbildung 10.1 dargestellt. Dabei
sind dort die Abläufe recht einfach dargestellt, in etwa so, wie sie im vorliegenden
Projekt stattfinden. Durch die Einflußorganisation bedingt liegt die
Entscheidungsgewalt über Änderungsanträge beim Auftraggeber.
Durch Änderungen ist häufig ein Modifizieren der Projektplanung nötig,
beispielsweise werden dem Projektstrukturplan neue Arbeitspakete hinzugefügt.
Durch eine Änderung – aber auch durch Unterlassen einer solchen –
kann sich dementsprechend sowohl die Ablauf- und Terminplanung als auch
die Kostenplanung ändern.
08-045 Kempf Danilo.pdf 93

10 WAHLELEMENTE
Beantragen
Bewerten/Genehmigen
Durchführen
Antragsteller:
Änderungsantrag
verfassen
Projektleiter:
Antrag aufnehmen
und prüfen
Betroffene:
Bewerte, Stellung
beziehen
Auftraggeber:
Entscheiden
Angenommen
Projektleiter:
Änderungsauftrag erteilen
Betroffene:
Änderungen durchführen
Projektleiter:
geänderte Dokumente
verteilen
Abgelehnt
Abbildung 10.1 Änderungsprozeß
Überarbeitung
Ja
Antrag modifizieren?
Nein
Änderung abgelehnt
94 Danilo Kempf

10.7 Projektstart und Projektende
PROJEKTSTART UND PROJEKTENDE 10.7
Ein kontrollierter Projektbeginn ist für den Projekterfolg außerordentlich
wichtig – gleichermaßen kommt auch einem systematischen Projektabschluß
eine große Bedeutung zu. Beides ist in den folgenden Abschnitten wiedergegeben.
10.7.1 Projektstart
Dem Projektstart bzw. der Projektstartphase kommt im Projektablauf eine besondere
Bedeutung zu. In diesem Abschnitt werden
• der Projektinhalt festgelegt
• die Projektziele ermittelt
• die Projektorganisationsform festgelegt
• Stakeholder ermittelt und eine Stakeholder-Analyse durchgeführt
• eine erste Risikoanalyse vollzogen
• ein Projektstrukturplan erstellt
• eine erste Einsatzmittelplanung durchgeführt
• das Projektteam formiert
• die Projektstartsitzung durchgeführt
Idealisiert findet die Projektstartphase nach Projektbeginn statt und das
Projektteam ist an Teilaufgaben der Startphase – beispielsweise an der
Zielfindung – in großem Umfang beteiligt. Diese Beteiligung wird durch
das Management-by-Objectives-Prinzip bzw. den kooperativen Führungsstil im
Grunde verlangt.
Im vorliegenden Fall waren Projektinhalt und – zumindest in grober, nicht
operationalisierter Form – Projektziele bereits vor Projektbeginn bekannt und
gegeben. Daher verweise ich hier auf den Abschnitt 1.2 Zielbeschreibung und
Zielhierarchie 〈S. 4〉.
Die restlichen Aufgaben der Projektstartphase habe ich planerisch in einer
kurzen Planungsphase zu Projektbeginn zusammengefaßt. Diese Planungsphase
beginnt bei offiziellem Projektstart ( 1) und endet mit 2.
Vor Beginn der Planungsphase und aus meiner Sicht vor Projektbeginn
fand im vorliegenden Projekt die Projektstartsitzung statt. Real war diese nicht
so formal, wie in der Literatur erwartet. Folgende Personen nahmen teil:
Auftraggeber
Michael Sieber und Burkhard Römer sind Geschäftsführer der Telco-
Soft GmbH und Projektauftraggeber. In dieser Rolle haben einzig sie
Entscheidungsbefugnisse. Beide haben naturgemäß großes Interesse am
Projekterfolg und sind Machtpromotoren.
08-045 Kempf Danilo.pdf 95

10 WAHLELEMENTE
Entwickler/TelAPI
Martin Riedel ist einer der Entwickler der Telco-Soft TelAPI-Lösung und
Initiator der Projektidee. Er ist in der TelAPI-Entwicklung sehr tief involviert
und außerordentlich an einer technisch sinnvollen Lösung interessiert.
Für dieses Projekt gilt er als Fachpromotor.
Projektleiter
In meiner Rolle als Projektleiter (und auch als Entwickler der TelAPI-
Lösung) war ich natürlich ebenfalls an der Projektstartsitzung beteiligt.
Während dieser Projektstartsitzung wurden folgende Themenkomplexe
erörtert:
Zielsetzung
Die Auftraggeber erläuterten die groben Zielvorgaben für das Projekt.
Diese wurden in Ergebnis- und Vorgehensziele aufgeteilt und in operationalisierter
Form schriftlich fixiert.
Als Oberziel wurde festgelegt:
• Schaffung einer Adapterlösung von AFP NetStar auf Telco-Soft TelAPI
Es existieren folgende Ergebnisziele:
• AFP-Schnittstelle ist dokumentiert
• eine Adaptionssoftware von AFP- auf Telco-Soft-Schnittstelle ist
implementiert
• die Software erfüllt alle Qualitätskriterien
• eine demonstrierbare Version ist bist zur CeBIT 2008 verfügbar
• die ehemaligen Mitarbeiter der AFP GmbH sind in das Team integriert
Vorgehensziele sind:
• ein Projektfinanzierungsplan liegt bis zum 5. November 2007 vor
• das Projekt ist bis spätestens zum 30. April 2008 abgeschlossen
• die Projektbudget ist eingehalten
In exakterer Form sind die Projektziele gemeinsam mit Betrachtung der
Zielbeziehungen im Abschnitt 1.2 Zielbeschreibung und Zielhierarchie
〈S. 4〉 und den darauf folgenden Seiten wiedergegeben.
Stakeholder
Es wurden die für das Projekt relevanten Stakeholder identifiziert. Dies
wurde in weniger umfangreicher Form als durch die in Abschnitt 2.2
Stakeholder 〈S. 17〉 wiedergegebene Stakeholderanalyse durchgeführt.
Insbesondere wurde erörtert, welche (potentiellen) Kunden der Telco-
Soft GmbH neben der Imaginary Networks AG ebenfalls Interesse an
der im Projektverlauf erstellten Lösung haben könnten sowie welche
Stakeholder für den Projektverlauf möglicherweise problematisch sein
könnten.
96 Danilo Kempf

PROJEKTSTART UND PROJEKTENDE 10.7
Termine
Auf Basis des technischen Lösungsvorschlags von Martin Riedel wurde
gemeinsam eine grobe Zeit- und Aufwandsabschätzung getroffen.
Diese galt es natürlich im Zuge der Planungsphase zu konkretisieren.
Diese erste Zeitabschätzung führte jedoch zur ungefähren Vorgabe der
Projekttermine:
Projektbeginn
Projektbeginn ist der 1. November 2007.
Projektende
Spätestes Projektende ist der 30. April 2008.
CeBIT 2008
Da der Projektverlauf die CeBIT 2008 umschließt, liegt zu Beginn
der Messe eine demonstrierbare Version der zu schaffenden Softwarelösung
vor.
Einführung
Konkrete Einführungstermine gibt es nicht – die erstellte Lösung
wird nicht direkt in den Wirkbetrieb überführt. Vor Projektende
wird die Lösung jedoch beim Kunden in Testbetrieb genommen.
Konkrete Terminvorgaben gibt es dazu nicht.
Kosten
Vom Auftraggeber wird für das Projekt ein Budget von maximal
e 250.000 eingeräumt. Im Zuge einer ersten gemeinsamen Kostenschätzung
wurde ermittelt, ob mit diesem Budget eine Projektumsetzung
überhaupt denkbar ist.
Risiken
Die Projektrisiken wurden gemeinsam ermittelt. Dies sind:
• Widerstand durch die ehemaligen Mitarbeiter der AFP GmbH
• mangelnde Akzeptanz der Lösung beim Kunden
• CeBIT-Termin möglicherweise nicht haltbar
• Projektabschlußtermin möglicherweise nicht haltbar
• Umsetzbarkeit nicht sichergestellt
• Qualität nicht ausreichend
• Überlastung des Projektteams
• Überlastung der Laborkapazität
Die hier ermittelten Projektrisiken werden im Kapitel 3 Risikoanalyse
〈S. 23〉 einer genaueren Betrachtung unterzogen.
Phasenplanung
Weiterhin wurde im Zuge der Projektstartsitzung die Phasenplanung
vorgenommen, das Projekt also in diskrete Phasen aufgeteilt. Dies sind:
• Planungsphase
• Analysephase
08-045 Kempf Danilo.pdf 97

10 WAHLELEMENTE
• Entwurfsphase
• Implementierungsphase
• Testphase
• Abschlußphase
Zusätzlich wurden die Projektmeilensteine festgelegt. Weitere Informationen
zu den Projektphasen und Meilensteinen finden sich im Kapitel
5 Phasenplanung 〈S. 37〉.
Die Projektstartsitzung fand Mitte Oktober 2007 statt. Mit dem Projektbeginn
am 1. November 2007 habe ich in meiner Aufgabe als Projektleiter die
Ergebnisse dieser Sitzung in konkrete Planungsschritte einbezogen, die in den
jeweils referenzierten Abschnitten dieses Transfernachweises wiedergegeben
sind.
10.7.2 Projektende
Ein Projekt läuft nach Fertigstellung der zu erbringenden Leistung nicht einfach
aus – vielmehr findet ein systematischer Projektabschluß statt. Zu diesem
gehören:
Abnahme
Zunächst erfolgt die Abnahme der erstellten Software durch den Auftraggeber.
Dabei stützt sich dieser auf die Berichte, die während der
Projektdurchführung erstellt wurden, insbesondere auf den Testberichte,
die zum Ende der Testphase erstellt wurden. Es erfolgt ein Abnahmegespräch
an dem Auftraggeber, Projektleiter und ein Entwickler beteiligt
sind.
Ermitteln offener Leistungen
Es wird ermittelt, welche Leistungen noch zu erbringen sind – dies
könnten beispielsweise die Erstellung von Dokumentation oder die Unterstützung
des Kunden beim Testbetrieb oder bei der gegebenenfalls
später stattfindenden Überführung in den Wirkbetrieb sein.
Überprüfung der Finanzsituation
Die tatsächlichen Projektkosten und die Erträge werden durch den Projektcontroller
auf Korrektheit geprüft. Im vorliegenden Projekt entstehen
freilich keine unmittelbaren Erträge, da Projektziel zunächst nur die
Schaffung einer Lösung für den Testbetrieb ist und die Kosten zunächst
voll durch die Telco-Soft GmbH getragen werden.
interne Übergabe
Der im Projektverlauf erstelle Softwarequelltext und die technische Dokumentation
wird in das Versionskontrollsystem der Telco-Soft GmbH
eingepflegt und wird zum Bestandteil des Produktes TelAPI . Dem Projekt
nachgelagert sind die Schulung der Support-Mitarbeiter und die Erstellung
von Briefing-Unterlagen für weitere Mitarbeiter (Technik, Vertrieb).
98 Danilo Kempf

PROJEKTSTART UND PROJEKTENDE 10.7
Übergabe an Kunden
Dem Kunden wird die Lösung inclusive Dokumentation für seinen
Testbetrieb übergeben, er wird über das Projektende informiert. Dem
Kunden wird ein technischer Ansprechpartner für Anfragen und
Änderungswünsche genannt.
Aufgaben der Beziehungsebene
Die in der Literatur genannten Probleme der Beziehungsebene sind im
vorliegenden Projekt nicht zu erwarten, da ja die grundlegende Teamstruktur
auch nach Projektende bestehen bleibt. Letztlich bleibt hier lediglich
die Aufgabe, die Projektarbeit mit allen Mitarbeitern feierlich
ausklingen zu lassen.
Für ein systematisches Projektende ist eine Projektabschlußsitzung empfehlenswert,
die im vorliegenden Projekt auch – in weniger formaler Form – zum
Meilenstein 8 durchgeführt wurde. In einer solchen Abschlußsitzung werden
die folgenden Punkte angesprochen:
Fazit
Als Projektleiter ziehe ich ein Fazit zur Projektdurchführung und
erörtere, welche Projektziele erreicht und welche verfehlt wurden.
Feedback
Mit den Projektmitarbeitern werden Stärken und Schwächen im Projektablauf
erörtert. Jeder Teilnehmer kann positive aber auch negative
Aspekte des Projektablaufes äußern. Gegebenenfalls erfolgt im Anschluß
eine Aussprache zu dieser Feedback-Runde, wichtige Punkte
können also direkt detailliert diskutiert werden.
Projektlernen
Es wird diskutiert, wie sichergestellt werden kann, daß die Erfahrungen
aus dem vorliegenden Projekt für künftige Projekte nutzbar gemacht
werden können. Es wird geklärt, welche Maßnahmen getroffen werden
können, um Fehler im Projektablauf künftig vermeidbar zu machen.
Aufgabenverteilung
Sollten noch offene Leistungen aus dem Projektverlauf verbleiben, werden
diese über das Projektende hinaus an die einzelnen Mitarbeiter vergeben.
Im Anschluß erstelle ich in meiner Rolle als Projektleiter den Projektabschlußbericht,
der Teil der Projektdokumentation ist. Weitere Informationen zu
diesem Bericht enthält der folgende Abschnitt.
08-045 Kempf Danilo.pdf 99

10 WAHLELEMENTE
10.9 Projektberichtswesen und Projektdokumentation
10.9.1 Berichtswesen
Der Begriff Projektberichtswesen beschreibt das systematische Dokumentieren
projektrelevanter Abläufe und Informationen. Auf Basis von Berichten lassen
sich den Projektablauf steuernde Entscheidungen treffen.
Bereits bei Projektbeginn muß durch den Projektleiter und den Controller
(beziehungsweise in diesem konkreten Projekt den Auftraggeber) festgelegt
werden, welche Berichte zu erstellen sind. Dabei sind folgende Faktoren relevant:
• Inhalt und Form der Berichte
• Wer berichtet an wen?
• Zeitpunkt und Frequenz der Berichte
Für dieses Projekt gilt folgender Berichtsplan:
Bericht von an Termin
Statusberichte
(Formblatt)
AP-Verantwortliche
Projektleiter im Schnitt alle drei
Arbeitstage, bei
Problemen oder
Verzug häufiger
Projektleiter zum Ende der
Testberichte technische
Mitarbeiter
Testphase
gesammelter Projektleiter Mitarbeiter alle drei
Statusbericht
(schriftlich)
Arbeitstage
Fortschrittsbe- Projektleiter Auftraggeber zu den
richt
Meilensteinen, in
(schriftlich)
der
Implementierungsund
Testphase
einmal pro Woche
Status-Updates Projektleiter Kunde wöchentlich
Status-Updates Projektleiter weitere MA sporadisch
Abschlußbericht Projektleiter Auftraggeber zum
Projektabschluß
Die Berichtsstruktur ist also dergestalt, daß die Arbeitspaket-
Verantwortlichen im Schnitt alle drei Arbeitstage einen kurzen, formblattbasierten
Statusbericht an mich als Projektleiter abgeben. Die Kombination
dieser Fortschrittsberichte wird von mir aufbereitet und in Form eines schriftlichen
Statusberichts an alle Projektmitarbeiter zurück kommuniziert. Die
100 Danilo Kempf

PROJEKTBERICHTSWESEN UND PROJEKTDOKUMENTATION 10.9
so gewonnenen Informationen zur Fortschrittsgradmessung herangezogen
und dienen als Datenbasis zur Pflege des laufenden Projektkalenders. Ein
exemplarisches Formular für einen solchen Statusbericht findet sich in Abbildung
10.2.
Die Fortschrittsinformationen werden von mir verdichtet dem Auftraggeber
einmal wöchentlich in Form eines kurzen Berichtes übermittelt. Während
der frühen Projektphasen, also während Analyse und Entwurf, ist die Erstellung
eines solch granulierter Fortschrittsbericht schlecht möglich. In diesem
Phasen wird zu ihrem jeweiligen Ende, also zu den Phasenabschlußmeilensteinen,
einmalig zusammenfassend berichtet.
Dem Kunden wird wöchentlich in Form einer kurzen Status-E-Mail der
Projektfortschritt kommuniziert.
Bei Projektende erstelle ich einen detaillierten Projektabschlußbericht,
der die vollständige Projektdokumentation zusammenfaßt und das Projekt
mit Fazit-Charakter abschließend dokumentiert. Dieser Abschlußbericht erscheint
mir, neben dem konkreten technischen Output, als eines der wichtigsten
durch das Projekt produzierten Dokumente – schließlich wird dieser Bericht
bei Folgeprojekten als Erfahrungsbasis herangezogen und dient damit
auch direkt dem Projektlernen. Der Abschlußbericht enthält im Wesentlichen
die folgenden Informationen:
zeitlicher Ablauf
Enthalten sind geplanter sowie erzielter Endtermin und gegebenenfalls
die Begründung für das Nichterreichen des originar geplanten Endtermins.
Ziele
Die Projektziele, die erreicht bzw. nicht erreicht wurden. Konnten Ziele
nicht erreicht werden, muß der Grund dafür ermittelt und wiedergegeben
werden
Kosten
Informationen sowohl über die geplanten als auch über die
tatsächlichen Projektkosten und eine Begründung für gegebenenfalls
aufgetretene Abweichungen.
Lessons Learned
Was ist gut, was ist schlecht gelaufen? Sind Schwierigkeiten aufgetreten,
wie wurde diesen begegnet? Gab es Konflikte im Team?
Konsequenzen
Was kann in zukünftigen Projekten besser gemacht werden?
offene Punkte
Was ist nach Projektende zu erledigen?
08-045 Kempf Danilo.pdf 101

10 WAHLELEMENTE
Statusbericht
Projekt Schnittstellenmigration/netzintegrierter Anrufbeantworter
Von An
Arbeitspaket Datum
Das Arbeitspaket läuft:
wie geplant.
nicht wie geplant. Abweichungen sowie deren Ursachen und
getroffende Maßnahmen sind:
(Gegebenenfalls sind dem Statusbericht erläuternde Anlagen beizufügen.)
Der Fortschrittsgrad des Arbeitspakets beträgt zum Berichtszeitpunkt
%. (Nur bei explizit vereinbarter Fortschritssgradmessung auszufüllen.)
Anmerkungen/Entscheidungsbedarf:
(Gegebenenfalls sind dem Statusbericht erläuternde Anlagen beizufügen.)
Unterschrift
Abbildung 10.2 Formular für kurzen Statusbericht
102 Danilo Kempf

PROJEKTBERICHTSWESEN UND PROJEKTDOKUMENTATION 10.9
10.9.2 Projektdokumentation
Das Dokumentieren eines Projektes ist kein diskreter Arbeitsschritt sondern
kontinuierliches Sammeln und gegebenenfalls Verfügbarmachen aller projektrelevanten
Informationen. Alle das Projekt betreffenden Unterlagen werden
dabei zum Teil einer Projektakte. Im vorliegenden Projekt existiert statt einer
Akte im Wortsinne ein versionierter Projektordner im Groupware-System der
Telco-Soft GmbH.
Der Prozeß der Projektdokumentation bzw. des Dokumentierens
überschneidet sich freilich mit allen anderen Projektvorgängen – insbesondere
natürlich mit Konfigurations- und Änderungsmanagement.
Wichtig ist im Zuge der Projektdokumentation insbesondere,
• das alle Dokumente archiviert werden
• das alle Dokumentrevisionen und die Änderungen zwischen ihnen niedergelegt
werden
• das auch nach Projektende die Dokumentation zugänglich ist (dies ist
ggf. sogar gesetzlich erforderlich)
Für das vorliegende Projekt wurde eine elektronische Projektakte angelegt,
die als versionierte Ordnerstruktur im genutzten Groupware-System realisiert
wurde. Dies hat den gegenüber einer herkömmlichen Projektakte wesentliche
Vorteile:
• verschiedene Dokumentversionen werden automatisch gehandhabt
• Querverweise zwischen versionierten Dokumenten werden unterstützt
• es lassen sich Freigaben auf Ordner- und Dokumentebene realisieren
Die elektronische Projektakte ist wie folgt gegliedert:
Index Ordner
1 Rahmenbedingungen
1.1 Zieldefinitionen
1.2 Spezifikationen
1.3 Normen
1.4 Projektorganisation
2 Projektplanung
2.1 Phasenplanung und Meilensteine
2.2 Projektstrukturplan
2.3 Arbeitspaketbeschreibungen
2.4 Termine
2.5 Einsatzmittel
2.6 Kosten
3 Berichte
08-045 Kempf Danilo.pdf 103

10 WAHLELEMENTE
3.1 Statusberichte der AP-Verantwortlichen
3.2 Statusberichte des Projektleiters für die Mitarbeiter
3.3 Statusberichte des Projektleiters für den
Auftraggeber
3.4 Testberichte
3.4 weitere Berichte
4 Projektgegenstand
4.1 Dokumentation der AFP-Schnittstelle
4.2 Fachkonzept
4.3 Software-Architektur
4.4 Quelltexte
5 Kommunikation
5.1 Kommunikationsjournal
5.2 Besprechungsprotokolle
6 Diverses
Die elektronische Projektakte ist dabei sowohl mit dem Kommunikationsund
E-Mail-System verzahnt, als auch mit dem Versionskontrollsystem für
Softwarequelltexte. Durch diese Integration werden automatisch alle projektrelevanten
E-Mails der Projektakte beigeordnet und alle Quelltexte sowie
Quelltextänderungen automatisch für die Projektakte aufbereitet.
104 Danilo Kempf

Anhang
Abkürzungsverzeichnis
Im Fließtext und in den grafischen Darstellungen wurden vereinzelt
Abkürzungen verwendet. Diese werden grundsätzlich bei der ersten Verwendung
erläutert. Dieses Abkürzungsverzeichnis faßt alle genutzen
Abkürzungen zusammen:
Abkürzung Bedeutung
AF Anfangsfolge
AP Arbeitspaket
EF Endfolge
FAT frühester Anfangstermin
FAZ frühester Anfangszeitpunkt
FET frühester Endtermin
FEZ frühester Endzeitpunkt
FP freier Puffer
GP Gesamtpuffer
ISDN Integrated Services Digital Network
MA Mitarbeiter
Nf Nachfolger
Nf(P) Nachfolger im PSP-Code
NF Normalfolge
NGN Next Generation Networks
Nr Nummer
PSP Projektstrukturplan
RB Ressourcenbedarf
SAT spätester Anfangstermin
SAZ spätester Anfangszeitpunkt
SET spätester Endtermin
SEZ spätester Endzeitpunkt
UML Unified Modelling Language
Verantw. Verantwortlicher für ein Arbeitspaket
Vg Vorgänger
Vg(P) Vorgänger im PSP-Code
08-045 Kempf Danilo.pdf 105

Glossar
Auch wenn es sich beim vorliegenden Projekt um ein Entwicklungsprojekt im
IT-Bereich handelt, habe ich für diesen Transfernachweis im Wesentlichen auf
Fachtermini verzichtet und eine abstrakte Darstellung gewählt. Die Fachbegriffe,
die dennoch verwendet wurden, sollen in diesem Glossar kurz erläutert
werden.
Dienstmerkmale
bezeichnen im Zusammenhang mit Telefonie bzw. Telekommunikation
bestimmte Funktionen, die ISDN- oder NGN-Netze zur Verfügung stellen.
Dazu gehören beispielsweise Vermitteln, Rufweiterleitung und Telefonkonferenzen.
Integrated Services Digital Network (ISDN)
beschreibt einen Satz technischer Standard-Dokumente, die ein digitales
und weithin eingesetztes Kommunikationssystem definieren. Größtes
Anwendungsfeld von ISDN ist die Übermittlung von Sprachdaten (digitale
Telefonie), durch das Netz werden jedoch erheblich mehr Merkmale
unterstützt.
Netzintegrierter Anrufbeantworter
ist ein anderer Begriff für Mailbox und bezeichnet den Dienst, bei der der
Telefonieanbieter die Funktion des Anrufbeantworters zur Verfügung
stellt, ohne das am Teilnehmeranschluß ein spezielles Gerät installiert
sein muß. So ein Anrufbeantworter kann beispielsweise über Sprachmenüführung
konfiguriert und abgefragt werden. An modernen integrierten
Telefonen läßt sich so ein Anrufbeantworter aber auch über
Bildschirmsteuerung bedienen.
Next Generation Networks (NGN)
bezeichnet auf abstrakte Art Telekommunikationsnetze neuer Generation,
die die etablierten Technologien – beispielsweise ISDN – schrittweise
ablösen. Durch NGN verschmelzen traditionelle Telefonie und Datenübertragung
mit Internet-Technologien.
Telefonkonferenzen
bezeichnen ein Dienstmerkmal im ISDN oder in den NGN. Dabei werden
mehrere Telefonieteilnehmer miteinander verschaltet und können über
die klassische 1:1-Telefonie hinaus miteinander kommunizieren. Dabei
wird ein gemischtes Sprachsignal an alle Teilnehmer übetragen. Konferenzschaltungen
sind auch in der Videotelefonie möglich.
Unified Modeling Language
ist eine Modellierungssprache mit grafischer Notation, die für die Modellierung
von Softwaresystemen und damit als Kommunikationsmittel
im Entwicklungsprozeß eingesetzt wird.
106 Danilo Kempf

Abbildungsverzeichns
ABBILDUNGSVERZEICHNS
1.1 Zielhierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Zielhierarchie (alternative Darstellung) . . . . . . . . . . . . . . . . . . . 8
1.3 Zielbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Grafische Darstellung des Projektumfelds . . . . . . . . . . . . . . . . . 17
2.2 Stakeholderportfolio und Stakeholdersteuerung . . . . . . . . . . . . . . 19
2.3 Kommunikationsmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Mindmap zur Risikoermittlung . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 grafische Risikobewertung . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Stammorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 ein üblicher Eskalationsweg . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 tatsächlicher Eskalationsweg . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Grafischer Phasenplan . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1 Grafische Darstellung des Projektstrukturplans . . . . . . . . . . . . . . . 43
7.1 Netzplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.1 Mitarbeiterqualifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.2 Einsatzmittelplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.3 Auslastungsprofil für die Ressource Entwickler . . . . . . . . . . . . . . . 73
8.4 kapazitätstreuer Kapazitätsausgleich . . . . . . . . . . . . . . . . . . . . 74
8.5 termintreuer Kapazitätsausgleich . . . . . . . . . . . . . . . . . . . . . . 75
8.6 Kostenganglinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
8.7 Kostensummenlinie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
9.1 Johari-Fenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
10.1 Änderungsprozeß . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
10.2 Formular für kurzen Statusbericht . . . . . . . . . . . . . . . . . . . . . . 102
08-045 Kempf Danilo.pdf 107

Anlagen
vollständige Vorgangsliste
Als Anlage habe ich auf den folgenden Seiten die vollständige Vorgangsliste
wiedergegeben, die in den in diesem Transfernachweis aufgezeigten Planungsschritten
entstanden ist. Hier werden alle planerischen Daten für jeden
Vorgang kompakt dargestellt.
Aus Gründen der Kompaktheit sind die Feldüberschriften abgekürzt wiedergegeben.
Eine Erläuterung der genutzten Abkürzungen findet sich im
Abkürzungsverzeichnis 〈S. 105〉.
Vorgang Projekt Schnittstellenmigration/netzintegrierter Anrufbeantworter
durchführen
Nr 1 PSP-Code 1 Verantw. –
Vg – Nf – Dauer 107t
Vg(P) – Nf(P) – Kosten e 244.800
FAZ 0 FEZ 107 GP 0
SAZ 0 SEZ 107 FP 0
FAT 1. 11. 2007 FET 11. 4. 2008 RB –
SAT 1. 11. 2007 SET 11. 4. 2008 MA –
Vorgang Analysieren
Nr 2 PSP-Code 1.1 Verantw. –
Vg – Nf – Dauer 16t
Vg(P) – Nf(P) – Kosten e 51.400
FAZ 3 FEZ 19 GP 0
SAZ 3 SEZ 19 FP 0
FAT 6. 11. 2007 FET 27. 11. 2007 RB –
SAT 6. 11. 2007 SET 27. 11. 2007 MA –
Vorgang AFP-Schnittstelle dokumentieren
Nr 3 PSP-Code 1.1.1 Verantw. Michael Walm
Vg 30 Nf 4 Dauer 15t
Vg(P) 1.6.2.2 Nf(P) 1.1.2 Kosten e 18.000
FAZ 3 FEZ 18 GP 0
SAZ 3 SEZ 18 FP 0
FAT 6. 11. 2007 FET 26. 11. 2007 RB 2× Entwickler (NetStar)
SAT 6. 11. 2007 SET 26. 11. 2007 MA Michael Walm, Sören
Schneider
08-045 Kempf Danilo.pdf 109

ANLAGEN
Vorgang AFP-Schnittstellendokumentation präsentieren
Nr 4 PSP-Code 1.1.2 Verantw. Michael Walm
Vg 3 Nf 31 Dauer 1t
Vg(P) 1.1.1 Nf(P) 1.6.2.3 Kosten e 2.800
FAZ 18 FEZ 19 GP 0
SAZ 18 SEZ 19 FP 0
FAT 27. 11. 2007 FET 27. 11. 2007 RB 4× Entwickler, 1× Mitarbeiter/Dokumentation
SAT 27. 11. 2008 SET 27. 11. 2007 MA Martin Riedel, Thomas
Ernemann, Michael Walm,
Sören Schneider, Jürgen
Kurzmann
Vorgang Telco-Soft-Schnittstellendokumentation präsentieren
Nr 5 PSP-Code 1.1.3 Verantw. Thomas Ernemann
Vg 30 Nf 31 Dauer 1t
Vg(P) 1.6.2.2 Nf(P) 1.6.2.3 Kosten e 2.400
FAZ 3 FEZ 4 GP 15
SAZ 18 SEZ 19 FP 15
FAT 6. 11. 2007 FET 6. 11. 2007 RB 4× Entwickler
SAT 27. 11. 2007 SET 27. 11. 2007 MA Martin Riedel, Thomas
Ernemann, Michael Walm,
Sören Schneider
Vorgang Softwareanalyse im Testlabor durchführen
Nr 6 PSP-Code 1.1.4 Verantw. Lothar Karlson
Vg 30 Nf 31 Dauer 8t
Vg(P) 1.6.2.2 Nf(P) 1.6.2.3 Kosten e 14.400
FAZ 3 FEZ 11 GP 8
SAZ 11 SEZ 19 FP 8
FAT 6. 11. 2007 FET 15. 11. 2007 RB 3× technischer Mitarbeiter
SAT 16. 11. 2007 SET 27. 11. 2007 MA Lothar Karlson, Torben
Rahlich, Jens Wippel
Vorgang Imaginary Networks-Dokumentation sichten
Nr 7 PSP-Code 1.1.5 Verantw. Thomas Ernemann
Vg 30 Nf 31 Dauer 10t
Vg(P) 1.6.2.2 Nf(P) 1.6.2.3 Kosten e 12.000
FAZ 3 FEZ 13 GP 6
SAZ 9 SEZ 19 FP 6
FAT 6. 11. 2007 FET 19. 11. 2007 RB 2× Entwickler (TelAPI)
SAT 14. 11. 2007 SET 27. 11. 2007 MA Thomas Ernemann, Martin
Riedel
110 Danilo Kempf

VOLLSTÄNDIGE VORGANGSLISTE
Vorgang Lösung entwerfen
Nr 8 PSP-Code 1.2 Verantw. –
Vg – Nf – Dauer 20t
Vg(P) – Nf(P) – Kosten e 36.400
FAZ 19 FEZ 39 GP 0
SAZ 19 SEZ 39 FP 0
FAT 28. 11. 2007 FET 8. 1. 2008 RB –
SAT 28. 11. 2007 SET 8. 1. 2008 MA –
Vorgang Fachkonzept erstellen
Nr 9 PSP-Code 1.2.1 Verantw. Martin Riedel
Vg 31 Nf 10 Dauer 5t
Vg(P) 1.6.2.3 Nf(P) 1.2.2 Kosten e 9.600
FAZ 19 FEZ 24 GP 0
SAZ 19 SEZ 24 FP 0
FAT 28. 11. 2007 FET 4. 12. 2007 RB 4× Entwickler
SAT 28. 11. 2007 SET 4. 12. 2007 MA Martin Riedel, Thomas
Ernemann, Michael Walm,
Sören Schneider
Vorgang Fachkonzept erstellen
Nr 10 PSP-Code 1.2.2 Verantw. Martin Riedel
Vg 9 Nf 11 Dauer 3t
Vg(P) 1.2.1 Nf(P) 1.2.3 Kosten e 13.200
FAZ 24 FEZ 27 GP 0
SAZ 24 SEZ 27 FP 0
FAT 5. 12. 2007 FET 7. 12. 2007 RB 4× Entwickler, 4×
technischer Mitarbeiter
SAT 5. 12. 2007 SET 7. 12. 2007 MA Martin Riedel, Thomas
Ernemann, Michael Walm,
Sören Schneider, Lothar
Karlson, Jens Wippel,
Torben Rahlich, Jürgen
Kurzmann
Vorgang Softwarearchitektur definieren
Nr 11 PSP-Code 1.2.3 Verantw. Martin Riedel
Vg 10 Nf 12 Dauer 8t
Vg(P) 1.2.2 Nf(P) 1.2.4 Kosten e 4.800
FAZ 27 FEZ 35 GP 0
SAZ 27 SEZ 35 FP 0
FAT 10. 12. 2007 FET 19. 12. 2007 RB 2× Entwickler (TelAPI)
SAT 10. 12. 2007 SET 19. 12. 2007 MA Martin Riedel, Thomas
Ernemann
08-045 Kempf Danilo.pdf 111

ANLAGEN
Vorgang Testprotokoll definieren
Nr 12 PSP-Code 1.2.4 Verantw. Torben Rahlich
Vg 11 Nf 32 Dauer 4t
Vg(P) 1.2.4 Nf(P) 1.6.2.4 Kosten e 6.400
FAZ 35 FEZ 39 GP 0
SAZ 35 SEZ 39 FP 0
FAT 20. 12. 2007 FET 8. 1. 2008 RB 2× Entwickler (TelAPI), 1×
technischer Mitarbeiter
SAT 20. 12. 2007 SET 8. 1. 2008 MA Torben Rahlich, Martin
Riedel, Thomas Ernemann
Vorgang Softwareentwurf umsetzen
Nr 13 PSP-Code 1.3 Verantw. –
Vg – Nf – Dauer 50t
Vg(P) – Nf(P) – Kosten e 125.200
FAZ 39 FEZ 89 GP 0
SAZ 39 SEZ 89 FP 0
FAT 9. 1. 2008 FET 18. 3. 2008 RB –
SAT 9. 1. 2008 SET 18. 3. 2007 MA –
Vorgang implementieren
Nr 14 PSP-Code 1.3.1 Verantw. Martin Riedel
Vg 32 Nf 15AF+30t,
16AF+20t,
17AF+20t,34
Dauer 50t
Vg(P) 1.6.2.4 Nf(P) 1.3.2AF+30t,
1.3.3AF+20t,
1.3.4AF+20t,
1.6.2.6
Kosten e 96.000
FAZ 39 FEZ 89 GP 0
SAZ 39 SEZ 89 FP 0
FAT 9. 1. 2008 FET 18. 3. 2008 RB 4× Entwickler
SAT 9. 1. 2008 SET 18. 3. 2007 MA Martin Riedel, Thomas
Ernemann, Michael Walm,
Sören Schneider
Vorgang CeBIT-Version erstellen
Nr 15 PSP-Code 1.3.2 Verantw. Danilo Kempf
Vg 14AF+30t Nf 33 Dauer 5t
Vg(P) 1.3.1AF+30t Nf(P) 1.6.2.5 Kosten e 2.400
FAZ 59 FEZ 64 GP 4
SAZ 63 SEZ 68 FP 4
FAT 20. 2. 2008 FET 26. 2. 2008 RB 1× Entwickler
SAT 26. 2. 2008 SET 3. 3. 2008 MA Danilo Kempf
112 Danilo Kempf

VOLLSTÄNDIGE VORGANGSLISTE
Vorgang begleitende Funktionstests durchführen
Nr 16 PSP-Code 1.3.3 Verantw. Jens Wippel
Vg 14AF+20t Nf 34 Dauer 30t
Vg(P) 1.3.1AF+20t Nf(P) 1.6.2.6 Kosten e 12.800
FAZ 59 FEZ 89 GP 0
SAZ 59 SEZ 89 FP 0
FAT 6. 2. 2008 FET 18. 3. 2008 RB 1× technischer Mitarbeiter
SAT 6. 2. 2008 SET 18. 3. 2008 MA Jens Wippel
Vorgang dokumentieren
Nr 17 PSP-Code 1.3.4 Verantw. Jürgen Kurzmann
Vg 14AF+20t Nf 34 Dauer 20t
Vg(P) 1.3.1AF+20t Nf(P) 1.6.2.6 Kosten e 8.000
FAZ 59 FEZ 79 GP 10
SAZ 69 SEZ 89 FP 10
FAT 6. 2. 2008 FET 4. 3. 2008 RB 1× Mitarbeiter/Dokumentation
SAT 20. 2. 2008 SET 18. 3. 2008 MA Jürgen Kurzmann
Vorgang Testen
Nr 18 PSP-Code 1.4 Verantw. –
Vg – Nf – Dauer 10t
Vg(P) – Nf(P) – Kosten e 23.200
FAZ 89 FEZ 99 GP 0
SAZ 89 SEZ 99 FP 0
FAT 19. 3. 2008 FET 1. 4. 2008 RB –
SAT 19. 3. 2008 SET 1. 4. 2008 MA –
Vorgang verifizieren, Defekte beheben
Nr 19 PSP-Code 1.4.1 Verantw. Torben Rahlich
Vg 34 Nf 35, 20AF+3t Dauer 100t
Vg(P) 1.6.2.6 Nf(P) 1.6.2.7, Kosten e 13.400
1.4.2AF+3t
FAZ 89 FEZ 99 GP 0
SAZ 89 SEZ 99 FP 0
FAT 19. 3. 2008 FET 1. 4. 2008 RB 2× technischer Mitarbeiter,
3× Entwickler (zu 25%)
SAT 19. 3. 2008 SET 1. 4. 2008 MA Torben Rahlich, Martin
Riedel, Thomas Ernemann,
Michael Walm
08-045 Kempf Danilo.pdf 113

ANLAGEN
Vorgang analysieren, profilieren, Probleme beseitigen
Nr 20 PSP-Code 1.4.2 Verantw. Lothar Karlson
Vg 19AF+3t Nf 35 Dauer 5t
Vg(P) 1.4.1AF+3t Nf(P) 1.6.2.7 Kosten e 5.600
FAZ 92 FEZ 97 GP 2
SAZ 94 SEZ 99 FP 2
FAT 24. 3. 2008 FET 28. Märu RB 1× technischer Mitarbeiter,
2008
3× Entwickler (zu 25%)
SAT 26. 3. 2008 SET 1. 4. 2008 MA Lothar Karlson, Martin
Riedel, Thomas Ernemann,
Michael Walm
Vorgang Dokumentation prüfen
Nr 21 PSP-Code 1.4.3 Verantw. Martin Riedel
Vg 34 Nf 35 Dauer 2t
Vg(P) 1.6.2.6 Nf(P) 1.6.2.7 Kosten e 1.200
FAZ 89 FEZ 91 GP 8
SAZ 97 SEZ 99 FP 8
FAT 19. 3. 2008 FET 20. 3. 2008 RB 1× Entwickler (TelAPI)
SAT 31. 3. 2008 SET 1. 4. 2008 MA Martin Riedel
Vorgang Inbetriebnahme
Nr 22 PSP-Code 1.5 Verantw. –
Vg – Nf – Dauer 6t
Vg(P) – Nf(P) – Kosten e 5.000
FAZ 99 FEZ 105 GP 0
SAZ 99 SEZ 105 FP 0
FAT 2. 4. 2008 FET 9. 4. 2008 RB –
SAT 2. 4. 2008 SET 9. 4. 2008 MA –
Vorgang Installationspaket erstellen
Nr 23 PSP-Code 1.5.1 Verantw. Thomas Ernemann
Vg 35 Nf 24 Dauer 1t
Vg(P) 1.6.2.7 Nf(P) 1.5.2 Kosten e 600
FAZ 99 FEZ 99 GP 0
SAZ 99 SEZ 99 FP 0
FAT 2. 4. 2008 FET 2. 4. 2008 RB 1× Entwickler (TelAPI)
SAT 2. 4. 2008 SET 2. 4. 2008 MA Thomas Ernemann
Vorgang Abnahme mit Auftraggeber durchführen
Nr 24 PSP-Code 1.5.2 Verantw. Danilo Kempf
Vg 23 Nf 25 Dauer 1t
Vg(P) 1.5.1 Nf(P) 1.5.3 Kosten e 1.200
FAZ 100 FEZ 100 GP 0
SAZ 100 SEZ 100 FP 0
FAT 3. 4. 2008 FET 3. 4. 2008 RB 1× Projektleiter, 1×
Entwickler
SAT 3. 4. 2008 SET 3. 4. 2008 MA Danilo Kempf, Martin
Riedel
114 Danilo Kempf

VOLLSTÄNDIGE VORGANGSLISTE
Vorgang Lösung bei der Imaginary Networks AG in Testbetrieb nehmen
Nr 25 PSP-Code 1.5.3 Verantw. Torben Rahlich
Vg 24 Nf 36 Dauer 4t
Vg(P) 1.5.2 Nf(P) 1.6.2.8 Kosten e 3.200
FAZ 101 FEZ 105 GP 0
SAZ 101 SEZ 105 FP 0
FAT 4. 4. 2008 FET 9. 4. 2008 RB 2× technischer Mitarbeiter
SAT 4. 4. 2008 SET 9. 4. 2008 MA Torben Rahlich, Jens Wippel
Vorgang Projektmanagement durchführen
Nr 26 PSP-Code 1.6 Verantw. –
Vg – Nf – Dauer 107t
Vg(P) – Nf(P) – Kosten e 16.800
FAZ 0 FEZ 107 GP 0
SAZ 0 SEZ 107 FP 0
FAT 1. 11. 2007 FET 11. 4. 2008 RB –
SAT 1. 11. 2007 SET 11. 4. 2008 MA –
Vorgang Projektplanung erstellen
Nr 27 PSP-Code 1.6.1 Verantw. Danilo Kempf
Vg 29 Nf 30 Dauer 3t
Vg(P) 1.6.2.1 Nf(P) 1.6.2.2 Kosten e 1.800
FAZ 0 FEZ 3 GP 0
SAZ 0 SEZ 3 FP 0
FAT 1. 11. 2007 FET 5. 11. 2007 RB 1× Projektleiter
SAT 1. 11. 2007 SET 5. 11. 2007 MA Danilo Kempf
Vorgang Meilensteine kontrollieren
Nr 28 PSP-Code 1.6.2 Verantw. –
Vg – Nf – Dauer 107t
Vg(P) – Nf(P) – Kosten –
FAZ 0 FEZ 107 GP 0
SAZ 0 SEZ 107 FP 0
FAT 1. 11. 2007 FET 11. 4. 2008 RB –
SAT 1. 11. 2007 SET 11. 4. 2008 MA –
Vorgang 1 – Projektstart
Nr 29 PSP-Code 1.6.2.1 Verantw. –
Vg – Nf 27 Dauer –
Vg(P) – Nf(P) 1.6.1 Kosten –
FAZ 0 FEZ 0 GP 0
SAZ 0 SEZ 0 FP 0
FAT 1. 11. 2007 FET 1. 11. 2007 RB –
SAT 1. 11. 2007 SET 1. 11. 2007 MA –
08-045 Kempf Danilo.pdf 115

ANLAGEN
Vorgang 2 – Projektplanung abgeschlossen
Nr 30 PSP-Code 1.6.2.2 Verantw. –
Vg 27 Nf 3, 5, 6, 7, 38 Dauer –
Vg(P) 1.6.1 Nf(P) 1.1.1, 1.1.3,
1.1.4, 1.1.5,
1.6.3
Kosten –
FAZ 3 FEZ 3 GP 0
SAZ 3 SEZ 3 FP 0
FAT 5. 11. 2007 FET 5. 11. 2007 RB –
SAT 5. 11. 2007 SET 5. 11. 2007 MA –
Vorgang 3 – Analysephase abgeschlossen
Nr 31 PSP-Code 1.6.2.3 Verantw. –
Vg 4, 5, 6, 7 Nf 9 Dauer –
Vg(P) 1.1.2, 1.1.3, Nf(P) 1.2.1 Kosten –
1.1.4, 1.1.5
FAZ 19 FEZ 19 GP 0
SAZ 19 SEZ 19 FP 0
FAT 27. 11. 2007 FET 27. 11. 2007 RB –
SAT 27. 11. 2007 SET 27. 11. 2007 MA –
Vorgang 4 – Entwurfsphase abgeschlossen
Nr 32 PSP-Code 1.6.2.4 Verantw. –
Vg 12 Nf 14 Dauer –
Vg(P) 1.2.4 Nf(P) 1.3.1 Kosten –
FAZ 39 FEZ 39 GP 0
SAZ 39 SEZ 39 FP 0
FAT 8. 1. 2008 FET 8. 1. 2008 RB –
SAT 8. 1. 2008 SET 8. 1. 2008 MA –
Vorgang 5 – Begin CeBIT 2008
Nr 33 PSP-Code 1.6.2.5 Verantw. –
Vg 15 Nf 34 Dauer –
Vg(P) 1.3.2 Nf(P) 1.6.2.6 Kosten –
FAZ 78 FEZ 78 GP 0
SAZ 78 SEZ 78 FP 0
FAT 4. 3. 2008 FET 4. 3. 2008 RB –
SAT 4. 3. 2008 SET 4. 3. 2008 MA –
116 Danilo Kempf

Vorgang 6 – Umsetzungsphase abgeschlossen
Nr 34 PSP-Code 1.6.2.6 Verantw. –
Vg 14, 16, 17,
33
Nf 19, 21 Dauer –
Vg(P) 1.3.1, 1.3.3,
1.3.4,
1.6.2.5
Nf(P) 1.4.1, 1.4.3 Kosten –
FAZ 89 FEZ 89 GP 0
SAZ 89 SEZ 89 FP 0
FAT 18. 3. 2008 FET 18. 3. 2008 RB –
SAT 18. 3. 2008 SET 18. 3. 2008 MA –
Vorgang 7 – Testphase abgeschlossen
Nr 35 PSP-Code 1.6.2.7 Verantw. –
Vg 19, 20, 21 Nf 23 Dauer –
Vg(P) 1.4.1, 1.4.2, Nf(P) 1.5.1 Kosten –
1.4.3
FAZ 99 FEZ 99 GP 0
SAZ 99 SEZ 99 FP 0
FAT 1. 4. 2008 FET 1. 4. 2008 RB –
SAT 1. 4. 2008 SET 1. 4. 2008 MA –
Vorgang 8 – Inbetriebnahme beim Kunden abgeschlossen
Nr 36 PSP-Code 1.6.2.8 Verantw. –
Vg 25 Nf 39NF-3t Dauer –
Vg(P) 1.5.3 Nf(P) 1.6.4NF-3t Kosten –
FAZ 105 FEZ 105 GP 0
SAZ 105 SEZ 105 FP 0
FAT 9. 4. 2008 FET 9. 4. 2008 RB –
SAT 9. 4. 2008 SET 9. 4. 2008 MA –
Vorgang 9 – Projekt vollständig abgeschlossen
Nr 37 PSP-Code 1.6.2.9 Verantw. –
Vg 39 Nf – Dauer –
Vg(P) 1.6.4 Nf(P) – Kosten –
FAZ 107 FEZ 107 GP 0
SAZ 107 SEZ 107 FP 0
FAT 11. 4. 2008 FET 11. 4. 2008 RB –
SAT 11. 4. 2008 SET 11. 4. 2008 MA –
VOLLSTÄNDIGE VORGANGSLISTE
Vorgang begleitendes Projektmanagement durchführen
Nr 38 PSP-Code 1.6.3 Verantw. Danilo Kempf
Vg 30 Nf 39EF Dauer 104t
Vg(P) 1.6.2.2 Nf(P) 1.6.4EF Kosten e 12.600
FAZ 3 FEZ 107 GP 0
SAZ 3 SEZ 107 FP 0
FAT 6. 11. 2007 FET 11. 4. 2008 RB 1× Projektleiter
SAT 6. 11. 2007 SET 11. 4. 2008 MA Danilo Kempf
08-045 Kempf Danilo.pdf 117

ANLAGEN
Vorgang Projektdokumentation erstellen
Nr 39 PSP-Code 1.6.4 Verantw. Danilo Kempf
Vg 38EF,
36NF-3t
Nf 37 Dauer 5t
Vg(P) 1.6.3EF,
1.6.2.8NF-
3t
Nf(P) 1.6.2.9 Kosten e 2.400
FAZ 102 FEZ 107 GP 0
SAZ 102 SEZ 107 FP 0
FAT 7. 4. 2008 FET 7. 4. 2008 RB 1× Projektleiter
SAT 11. 4. 2008 SET 11. 4. 2008 MA Danilo Kempf
118 Danilo Kempf