Extrait
Inhaltsverzeichnis
1 Einleitung
1.1 Aufgabenstellung der Masterarbeit
1.2 Scope
2 Einführung in die Problemstellung
2.1 Projekt
2.2 Projektphasen
2.3 Die Phasen des Projektes und deren Dokumente
2.3.1 Projektidee
2.3.2 Dokumente der Phase Projektidee
2.3.3 Projektkonkretisierung, die Projektidee wird weiter verfolgt
2.3.4 Dokumente zu Projektkonkretisierung
2.3.5 Projektvorbereitung, Evaluierung
2.3.6 Dokumente der Projektvorbereitung
2.3.7 Die Entscheidung für das Projekt
2.3.8 Dokumente der Entscheidung
2.3.9 Projektstart
2.3.10 Dokumente des Projektstarts
2.3.11 Projektdurchführung
2.3.12 Dokumente der Projektdurchführung
2.3.13 Projektabschluss und Übernahme
2.3.14 Dokumente des Projektabschlusses und der Übernahme
2.3.15 Projektevaluierung
2.3.16 Dokumente der Projektevaluierung
2.3.17 Wartung und Betreuung
2.3.18 Dokumente der Wartung und Betreuung
2.4 Aufgaben des Projektmanagers
2.4.1 Kommunikation
2.4.2 Information
2.4.3 Informationsmanagement
2.4.4 Wissen
2.4.5 Termine
2.4.6 Meeting
2.4.7 Anforderungen
2.4.8 Planung
2.4.9 Kontrolle
2.4.10 Qualitätssicherung
2.5 Projektmanagement und Dokumentenmanagement
2.5.1 Benutzerrollen und -rechte, Zugriffsrechte
2.5.2 Sicherheit
2.5.3 Vertraulichkeit
2.5.4 Verfügbarkeit
2.5.5 Beständigkeit
2.5.6 Haltbarkeit und Permanenz
2.5.7 Versionierung
2.5.8 Protokollierung
2.5.9 Inhalt (semantische Anreicherung, Beschlagwortung)
2.5.10 Suche (semantische Informationen)
2.5.11 (Langzeit-)Archivierung
2.5.12 Vernichtung
2.5.13 Rechtliche Aspekte
2.5.14 Abgrenzung zu ECM und DMS
3 Projektkommunikation und Dokumente
3.1 Dimensionen der Kommunikation
3.1.1 Dimension Zeit
3.1.2 Dimension Raum
3.1.3 Dimension Zeit und Raum in Kombination
3.1.4 Dimension Kommunikationskanäle
3.1.5 Zeit und Raum in Kombination mit den Kommunikationskanälen
3.1.6 Dimension Anzahl Sender und Empfänger
3.1.7 Dimension des Formalismus
3.1.8 Dimensionen in der Projektarbeit
3.2 Klassifizierung der Kommunikation und deren Dokumente
3.3 Zusammenfassung: Projektphasen, Kommunikation und Dokumente
4 Nutzung von Microsoft SharePoint für Projekte
4.1 Anforderungsanalyse: Unterstützung des Projektmanagements durch SharePoint
4.1.1 Verfügbarkeit der Dokumentationen
4.1.2 Versionierung und Freigabe von Dokumenten
4.1.3 Langzeitarchivierung
4.1.4 Terminplanung und Terminsteuerung
4.1.5 Ressourcenplanung und -steuerung
4.1.6 Zugriff von Beteiligten auf das System
4.1.7 Nutzung alternativer Programme in der Zusammenarbeit
4.1.8 Berechtigungsvergabe
4.1.9 Benutzerverwaltung
4.1.10 Zugriffskontrolle
4.1.11 Protokollierung
4.1.12 Änderungen
4.1.13 Änderungen verfolgen
4.1.14 Änderungen des Inhaltes
4.1.15 Änderungen verfolgen durch Benachrichtigungen
4.1.16 Änderungen freigeben
4.1.17 Qualitätssicherung
4.1.18 Projekterfahrung sichern
4.2 Microsoft Office SharePoint Server Produktmatrix
4.3 Das Microsoft Office SharePoint Server 2007 Objektmodell
4.4 SharePoint Websitebibliotheken und Listen
4.4.1 Dokumentbibliothek
4.4.2 Formularbibliothek
4.4.3 Wiki-Seitenbibliothek
4.4.4 Bildbibliothek
4.4.5 Ankündigungen
4.4.6 Kontakte
4.4.7 Diskussionsrunde
4.4.8 Hyperlinks
4.4.9 Kalender
4.4.10 Aufgaben
4.4.11 Projektaufgaben
4.4.12 Problemverfolgung
4.4.13 Umfrage
4.4.14 Benutzerdefinierte Liste
4.4.15 Standardseite
4.4.16 Webpartseite
4.4.17 Websites und Arbeitsbereiche
4.5 Gegenüberstellung Anforderungen - Standard Lösungen
5 Erkenntnisse
5.1 Erfahrungen mit SharePoint
5.1.1 Allgemeines zur Installation einer SharePoint Umgebung
5.1.2 Allgemeines zum Arbeiten mit SharePoint
5.1.3 SharePoint und Dokumentenverwaltung
5.1.4 SharePoint und WIKI-Seitenbibliotheken
5.1.5 SharePoint und Terminverwaltung
5.1.6 SharePoint und Anlage von Sub-Strukturen
5.1.7 SharePoint Benachrichtigungen
5.1.8 SharePoint Dokumente als HTML oder PDF veröffentlichen
5.2 Anforderungen an Erweiterungen der Standardlösung
5.3 Zusammenfassung der Ergebnisse und Vorschläge für weitere Untersuchungen
5.3.1 Arbeiten mit Dokumenten
5.3.2 Arbeiten mit automatischen Benachrichtigungen
5.3.3 Arbeiten mit Aufgaben und Projektaufgaben
5.3.4 Lizenzfrage bei Integration externer Partner
5.3.5 Integration externer Partner
5.4 Die wichtigsten Vorteile
5.5 Ausblick auf zukünftige Arbeiten
6 Anhang
6.1 Glossar
6.2 Berechtigungen in SharePoint
6.2.1 Listenberechtigungen
6.2.2 Websiteberechtigungen
6.2.3 Persönliche Berechtigungen
7 Literatur
Abbildungsverzeichnis
Abb. 2-1 Risk Breakdown Structure {Project Management Institute 2008 #56: 280}
Abb. 2-2: dynamisches Projektdreieck nach {Peipe 2009 #3,. 69}
Abb. 2-3 Das 'magische Dreieck' des Projekterfolges {Koreimann 2005 #5: 13}
Abb. 2-4 Beispiel eines Organigramms
Abb. 2-5 Wasserfallmodell
Abb. 2-6 Beispiel eines Projektstrukturplans
Abb. 2-7 Überlappende Phasen {Litke 2002 #47: 30}
Abb. 2-8 Project closure process {Roberts 2007 #38: 230}
Abb. 2-9 Qualitätssicherungsschirm {Burke 2004 #4: 307}
Abb. 2-10 Organigramm mit Berücksichtigung der Rolle der Administratoren des Systems
Abb. 3-1 Die 4 Seiten einer Nachricht {Schulz von Thun 1981 #46}
Abb. 4-1 Projektmanagement Prozesse
Abb. 4-2 Microsoft Education Microsoft Office SharePoint Server Compatibility (Part 1)
Abb. 4-3 Microsoft Education Microsoft Office SharePoint Server Compatibility (Part 2)
Abb. 4-4 SharePoint Features {English 2007 #52: 44-45}
Abb. 4-5 SharePoint Architektur und Objektmodell
Abb. 4-6 SharePoint Architektur und Objektmodell überarbeitet
Abb. 4-7 SharePoint Dokumentenbibliothek
Abb. 4-8 SharePoint Aktionen: Einbinden als WebDAV oder in Outlook
Abb. 4-9 SharePoint Dokumentenbibliothek als WebDAV Webordner
Abb. 4-10 SharePoint Dokumentenbibliothek als Outlook SharePoint Liste
Abb. 4-11 SharePoint Dokumentenbibliothek Vorlagen
Abb. 4-12 SharePoint Mehrfach Dokumentenupload
Abb. 4-13 SharePoint Versionskontrolle aktivieren
Abb. 4-14 SharePoint Einchecken eines Dokumentes
Abb. 4-15 SharePoint Auschecken eines Dokumentes direkt im Office 2007 Programm
Abb. 4-16 SharePoint Metadaten Verwaltung
Abb. 4-17 SharePoint Metadaten in Office 2007 Programmen im Zugriff
Abb. 4-18 SharePoint Dokumenteigenschaften, Metadaten bearbeiten
Abb. 4-19 SharePoint Definition Spalte für Metadaten
Abb. 4-20 SharePoint Berechtigungen vergeben
Abb. 4-21 SharePoint Standardberechtigungen
Abb. 4-22 SharePoint Berechtigungsstufen anpassen
Abb. 4-23 SharePoint Beispiel für eine individuelle Berechtigungsstufe
Abb. 4-24 SharePoint Beispiel Berechtigungsvergabe an einzelnen Benutzer
Abb. 4-25 SharePoint Wiki Beispiel neue Seite anlegen
Abb. 4-26 SharePoint Wiki Beispiel neue Seite bearbeiten
Abb. 4-27 SharePoint Beispiel Bildbibliothek mit Anzeige der möglichen Aktionen
Abb. 4-28 SharePoint Bearbeitungsfenster für Metadaten
Abb. 4-29 SharePoint Beispiel für das Erstellen einer Ankündigung
Abb. 4-30 SharePoint Beispiel für die Anzeige einer Ankündigung
Abb. 4-31 SharePoint Beispiel Kontaktliste
Abb. 4-32 SharePoint Kontaktliste in Outlook eingebunden
Abb. 4-33 SharePoint Diskussionsrunde
Abb. 4-34 SharePoint Hyperlinks
Abb. 4-35 SharePoint Kalender
Abb. 4-36 SharePoint Kalender in Outlook verbunden und angezeigt
Abb. 4-37 SharePoint Aufgaben Liste
Abb. 4-38 SharePoint Aufgaben in Outlook
Abb. 4-39 SharePoint Projektaufgaben
Abb. 4-40 SharePoint Beispiel Ergebnis einer Umfrage
Abb. 5-1 SharePoint Drei-Schichten-Serverfarm Modell
Abb. 5-2 Offline Bearbeitungsmodus
Abb. 5-3 SharePoint Dokument Auschecken
Abb. 5-4 SharePoint Dokument direkt in MS Office 2007 Applikation auschecken
Abb. 5-5 SharePoint Dokument Abfrage einchecken
Abb. 5-6 Microsoft Word 2007 Optionen Standardeinstellung bzgl. Speichern
Abb. 5-7 SharePoint Dokument Metadaten direkt in der Applikation bearbeiten
Abb. 5-8 SharePoint WIKI mit Übersicht über die Versionen
Abb. 5-9 SharePoint und die Anlage neuer Substrukturen
Abb. 5-10 SharePoint Negativbeispiel einer URL
Abb. 5-11 SharePoint Benachrichtigung einstellen
Abb. 5-12 SharePoint Benachrichtigung über die aktivierte Benachrichtigung
Abb. 5-13 SharePoint Benachrichtigung über neues Dokument
Abb. 5-14 SharePoint Benachrichtigung Quelltext
Abb. 5-15 SharePoint Benachrichtigung als "nur-Text" ohne Hyperlinks
Abb. 5-16 SharePoint HTML Viewer Konfiguration
Tabellenverzeichnis
Tabelle 2.1 Checkliste Kennzeichen Projekt {Peipe 2009 #3: 30}
Tabelle 2.2 Beispiel einer RACIO Matrix
Tabelle 2.3 Beispiel einer AKV Matrix
Tabelle 2.4 Beispiel einer Aktivitätenliste
Tabelle 2.5 Beispiel Aufgabenliste mit EVA
Tabelle 2.6 Meilensteinplan {Peipe 2009 #3: 107}
Tabelle 2.7 Kommunikationsplan {Peipe 2009 #3: 143}
Tabelle 3.1 Kommunikation – Dimension Zeit
Tabelle 3.2 Kommunikation – Dimension Raum
Tabelle 3.3 Kommunikation – Dimension Zeit und Raum
Tabelle 3.4 Kommunikation – Dimension Kommunikationskanäle
Tabelle 3.5 Kommunikation – Zeit, Raum und Kommunikationskanäle
Tabelle 3.6 Kommunikation – Dimension Anzahl Sender und Empfänger
Tabelle 3.7 Kommunikation – Dimension Formalismus
Tabelle 3.8 Kommunikation – Dimensionen Anzahl Beteiligte und Formalismus
Tabelle 3.9 Projektphasen – Kommunikation – Dokumente
1 Einleitung
1.1 Aufgabenstellung der Masterarbeit
Im ersten Teil wird die Definition für den Begriff Projekt erstellt. Darauf werden die Phasen eines Projektes und ihre Arbeitsergebnisse aufgeschlüsselt.
In einem weiteren Schritt werden die Aufgaben des Projektmanagers definiert und in Hinblick auf Dokumentenmanagement kategorisiert. Augenmerk wird auf die unterschiedlichen Arten von Kommunikation gelegt.
Es wird evaluiert, inwieweit Microsoft Office SharePoint® Server 2007 (MOSS) den Projektmanager bei der Erfüllung seiner Aufgaben unterstützen kann. Die obigen Punkte werden zusammengeführt und klassifiziert. Es wird untersucht, wieweit SharePoint Standard-Lösungen für die gefundenen Anforderungsschwerpunkte existieren und genutzt werden können.
Im letzten Schritt werden Anforderungen an Erweiterungen erarbeitet. Dieser Anforderungskatalog kann in weiterer Folge für ein Entwicklungsprojekt genutzt werden, oder bei der Suche nach Produkten von Anbietern dienen, die auf SharePoint basierende Lösungen anbieten. Auch für die Evaluierung anderer Hersteller von Werkzeugen zur IT-gestützten Kollaboration kann diese Zusammenfassung hilfreich sein.
Es folgen eine Zusammenfassung und ein Ausblick auf zukünftige Forschungsmöglichkeiten. Eine annotierte Literaturliste sowie ein Glossar finden sich im Anhang.
Die Masterarbeit und die während der Erstellung anfallenden Nebendokumente werden in der Entwicklungsphase auf einer Testinstallation eines Microsoft Office SharePoint Server publiziert. Wenn es sinnvoll erscheint, werden in der Zusammenarbeit mit Herrn Univ. Doz. Dr. Risak, dem Masterarbeitsbetreuer, die Möglichkeiten des Microsoft SharePoint Server genutzt. Eine Masterarbeit ist ein sehr spezielles Projekt, mit im Wesentlichen nur zwei Projektbeteiligten. Es wurden nicht alle Möglichkeiten auf dieser Testinstallation in der Zusammenarbeit für die Masterarbeit angewendet, die in der Arbeit beschrieben sind. Es wurden von mir Tests mit eigens angelegten Testusern durchgeführt.
Die Ergebnisse der Untersuchung beziehen sich auf die Erfahrungen mit der Testinstallation für die Masterarbeit und Erfahrungen im Unternehmen des Masterarbeiterstellers.
Die ALPINE Bau GmbH nutzt Microsoft SharePoint für die interne Abwicklung von Projekten im Bereich der IT. Erste Erfahrungen konnten auch in der Zusammenarbeit mit externen Beratern gesammelt werden, die ebenfalls in diese Masterarbeit eingeflossen sind.
1.2 Scope
Die Masterarbeit bezieht sich auf Projekte zur Einführung von Nicht-Standard-Software aus der Sicht der IT-Abteilung des Betriebes. Als solche wird eine Software bezeichnet, deren Marktdurchdringung einerseits nicht allzu groß ist oder andererseits dadurch gekennzeichnet ist, dass sie durch Customizing an die Bedürfnisse des Kunden angepasst wird. Im Unterschied zu Software Entwicklungsprojekten wird bei Nicht-Standard-Software während der Implementierung keine Codierung in einer allgemein üblichen Programmiersprache durchgeführt, sondern meist eine Anpassung durch Parametrisierung oder durch eine Tool-spezifische Scriptsprache vorgenommen.
Ähnlich wie bei Software Entwicklungsprojekten werden die Anforderungen der Endanwender erfasst, analysiert und umgesetzt. Die Anpassungen müssen entsprechend getestet werden.
Die Einschränkung auf „Nicht-Standard-Software“ wurde vorgenommen, um die in der Arbeit vorgestellten Projektphasen abzugrenzen und die in diesen Phasen produzierten und zu verwaltenden Dokumente einerseits ausreichend anspruchsvoll und differenziert und andererseits überschaubar zu halten. Die Ergebnisse der Untersuchung können auf andere Projekte, auch außerhalb der IT, angewendet werden.
Die große Schwierigkeit des Projektmanagements besteht darin, die Beteiligten am aktuellen Stand zu halten. Es sind unterschiedliche Informationsbedürfnisse und Berechtigungen zu berücksichtigen.
Gesucht ist eine Plattform für Dokumentation, Information, gegebenenfalls auch Diskussion, die standortübergreifend funktioniert, also auch über die Grenzen des Firmennetzwerkes und von Standortnetzwerken hinaus. Sie soll einfach zu bedienen und schnell einsetzbar sein. Die Vorgaben, wenn möglich die IT-Strategie des Unternehmens, auf etablierte strategische Partner und aus Support Gründen auf namhafte Hersteller zu setzen, hat schnell zu einer Einschränkung auf ein spezielles Produkt geführt: Microsoft SharePoint. Daher wird in dieser Arbeit keine Entscheidungsfindung erarbeitet, sondern es wird dargestellt, welche Anforderungen durch das gewählte Produkt erfüllt werden. Es werden die Möglichkeiten der Nutzung in Korrelation zu den Projektphasen und ihren Dokumenten herausgearbeitet und mögliche und sinnvolle Erweiterungen des Standardproduktes dargestellt.
Das untersuchte Produkt „Microsoft Office SharePoint Server 2007“ basiert im Kern auf einem Webserver, dem IIS (Internet Information Server) von Microsoft. Darauf bauen eine Reihe von Werkzeugen auf, die von Microsoft als Websites, Webapplikationen und Webparts bezeichnet werden. Diese Werkzeuge dienen der Bereitstellung von Informationen und der Zusammenarbeit und werden in ihrer Gesamtheit als SharePoint bezeichnet. Es wäre möglich, dass es von anderen Anbietern oder unter Open Source Lizenz eine ähnliche Lösung gibt. Eine kurze Internet Recherche ergab, dass einige Open Source Angebote existieren, die sich selbst als kostenlose Alternative zu SharePoint darstellen. Jedoch bieten sie jeweils nur Teile der Funktionalitäten an. Mir sind keine vergleichbaren Tools bekannt. Dieser Aspekt entspricht auch nicht meinem Forschungsinteresse. Es wird in der Arbeit nicht weiter darauf eingegangen.
2 Einführung in die Problemstellung
2.1 Projekt
Die DIN-Norm 69901 definiert ein Projekt als
Projekt (en: project) Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist
BEISPIEL Zielvorgabe, zeitliche, finanzielle, personelle oder andere Begrenzungen, projektspezifische Organisation {Deutsches Institut für Normung. 2009 #35: 11}
Etwas knapper lautet die Definition in PMBOK, fourth edition
A project is a temporary endeavor undertaken to create a unique product, service, or result. {Project Management Institute 2008 #56: 5}
Die Begründung für die Abgrenzung zwischen Projekttätigkeiten und dem normalen Tagesgeschäft wird in den meisten Büchern, die sich mit Projektmanagement beschäftigen, im Detail dargelegt.
Ein Projekt ist einerseits eine Aufgabe und ein Plan, andererseits der Prozess der Umsetzung des Plans. Der Plan beschreibt den Weg zum Ziel und mit dem Umsetzungsprozess wird dieser Weg zum Ziel beschritten. Sowohl beim Planen wie auch beim Umsetzen müssen die Nebenbedingungen beachtet werden. Jedes Projekt hat zwei Ebenen: einmal das Planen/Konzipieren, zum anderen das Ausführen/Steuern. Daraus ergeben sich folgende Aspekte:
-> Statischer Aspekt: Ein Projekt ist ein ungewöhnliches Vorhaben mit einem definierten Ziel, dessen Umsetzung nicht Routine ist.
-> Dynamischer Aspekt: Ein Projekt ist ein Vorgehen zur Zielerreichung unter Berücksichtigung von Nebenbedingungen. {Litke 2002 #47: 17}
A project is a piece of work that is designed to bring about an agreed upon beneficial change within a fixed timeframe using specified resources. Projects usually require the coordinated activity of a number of people to achieve that outcome, and often incorporate an element of risk. {Hobbs 2009 #19: 6}
Sabine Peipe fasst es in ihrer Checkliste für die Überprüfung, ob das fragliche Vorhaben die Merkmale für ein Projekt erfüllt, zusammen:
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.1 Checkliste Kennzeichen Projekt {Peipe 2009 #3: 30}
Im Kontext der IT Abteilung eines Betriebes wird das Verwalten und Managen mehrerer Projekte als IT Portfolio Management bezeichnet. Die Benennung „Portfolio Management“ leitet sich aus dem Finanzmanagement ab. Das IT Portfolio Management wird in drei Teile gegliedert, das Applikations-Portfolio, das IT-Mitarbeiter Portfolio und das Projekt Portfolio. Im Applikations-Portfolio beschäftigt man sich mit der Situation der IT Abteilung in Bezug auf Infrastruktur und Applikationen, im IT-Mitarbeiter Portfolio mit den Mitarbeitern und deren Kompetenzen. Im Folgenden beschäftigen wir uns nur mit dem PPM (Project Portfolio Management), das sich mit den IT Projekten befasst.
Projekte eines Unternehmens werden in einem Projektportfolio zusammengefasst, wenn diese Projekte einer bestimmten Organisationseinheit zugeordnet sind. Wenn die Projekte zwei oder mehrere Organisationseinheiten betreffen, werden im Projektportfolio jene Projekte zusammengefasst, die starke Abhängigkeiten zueinander aufweisen oder das Potential zu Synergieeffekten besitzen.
Die Abhängigkeiten können inhaltlicher Natur sein oder die Ressourcen betreffen. Ressourcen können zum Beispiel Personen, Räume, Computer, Computerrechenleistung oder Softwarelizenzen für spezielle Programme sein.
2.2 Projektphasen
Jedes Projekt unterteilt sich in Phasen. Diese sind im Überblick:
- Projektidee
- Auftrag die Projektidee weiter zu verfolgen, Projektkonkretisierung
- Evaluierung, Projektvorbereitung
- Entscheidung und Freigabe
- Projektstart
- Projektdurchführung
- Projektabschluss und offizielle dokumentierte Übernahme
- Projektevaluierung
- Wartung und Betreuung
Zum Vergleich stellt Peter Hobbs in seinem Buch „Project Management“ 6 Phasen vor:
The six phases of a project:
Initiation: identifying the problem to be solved or opportunity to be exploited
Definition: refining your understanding of what you want to achieve, by when, and with what resources.
Planning: deciding in detail how to achieve the objective, timescales, resources, responsibilities and communications.
Control: doing the work, monitoring progress, and adjusting the plan according to need, Implementation: Passing what you have created over to those who will be using it, and helping them to adjust to any changes.
Implementation: passing what you have created over to those who will be using it, and helping them to adjust to any changes.
Review: assessing the outcome and looking back to see if there is anything you could have done differently or better {Hobbs 2009 #19: 8-9}
Ich werde im weiteren Verlauf die vorgestellten neun Phasen verwenden und in den folgenden Abschnitten näher erläutern. Die „Control“ und „Implementation“ Phasen von Hobbs entsprechen der Projektdurchführung, dem Projektabschluss, der Übernahme und der Phase Wartung und Betreuung und umfassen somit jene Phasen, in denen der Mehrwert geschaffen wird.
2.3 Die Phasen des Projektes und deren Dokumente
Die Beteiligten, deren Verantwortlichkeiten und Rollen, die daraus resultierenden Anforderungen an Persistenz, Verfügbarkeit, Sicherheit und Zugriffsberechtigungen der entstehenden Dokumente können sich im Laufe des Projektes ändern. Daher ist es notwendig, eine Aufschlüsselung der Projektphasen und deren Dokumente vorzunehmen.
Durch Arbeitsteilung und Übergabe von Phasen- und Arbeitsergebnissen an andere Projektmitarbeiter wird eine Dokumentation notwendig. Auch auf Grund von Nachverfolgbarkeit und gesetzlichen Bestimmungen kann es notwendig sein, Dokumente zu erstellen, zu verteilen und zu archivieren.
… Bevor Sie mächtige Software zum Planen und Verfolgen Ihres Scrum-Projektes einsetzen, empfehle ich Ihnen zunächst mit einfachen Hilfsmitteln und händisch die Pläne und Berichte zu erstellen. So stellen Sie sicher, dass Sie das Planen und Verfolgen beherrschen, bevor Sie sich von softwarebasierten Werkzeugen abhängig machen. {Pichler 2008 #6: 79}
2.3.1 Projektidee
Ein Mitarbeiter, ein Abteilungsleiter, ein Kunde oder eine Person der Geschäftsführung hat eine Idee um einen Geschäftsprozess zu verbessern oder erstmals in ein IT System zu implementieren. Diese Person wird in der Literatur als Initiator (engl. initiator) bezeichnet.
Identifying the initiator: as your first task, determine who had the original idea that led to your project. Project success requires that, at a minimum, you meet this person’s needs and expectations. {Portny 2007 #62: 26}
Falls die Idee aus der Geschäftsführung kommt ist die Zusicherung von Ressourcen, um diese weiter zu verfolgen, meist direkt gegeben. In den anderen Fällen wird der Initiator versuchen, einen Sponsor für das Projekt zu interessieren. Dieser Sponsor muss im Unternehmen in einer Position sein, in der er Kostenverantwortung für das Projekt übernehmen kann. Die Suche nach einem geeigneten Sponsor hängt von der Größe des Projektes ab, von der Anzahl der Beteiligten und von den zu erwartenden Kosten.
If you are in a position to choose your sponsor, your goal should be to achieve just the right balance between authority and accessibility. While it is generally helpful to have as senior a sponsor as possible, you also need someone for whom the project is significant enough to command their active interest. A sponsor who keeps up to date with your progress and is aware of potential or actual issues will be well placed to make decisions or help you overcome any opposition or obstacle to the project without the need for extensive briefing. You need to be able to consult your sponsor quickly when things go wrong and feel comfortable that you are more than just one commitment among many. {Hobbs 2009 #19: 14}
2.3.2 Dokumente der Phase Projektidee
Falls der Initiator einen Sponsor von dem Projekt überzeugen muss, werden bereits erste Dokumente erzeugt. Dies sind Präsentationen, ein Grobkonzept mit einer Kosten-Nutzenanalyse und möglicherweise bereits ein erster Zeitplan.
Um ein erstes Gefühl für den zu erwartenden Bedarf zu ermitteln, können die geplanten zukünftigen Benutzer befragt werden. Dies könnte durch ein Feedback-Formular oder über eine Online-Abstimmungslösung erfolgen.
Um für spätere ähnliche Projekte zu lernen, sollten diese Informationen an zentraler Stelle, dem Projektportfoliobereich oder dem gemeinsam übergeordneten Bereich, zur Verfügung stehen.
Multiprojektmanagement (en: multiproject management) organisatorischer und prozessualer Rahmen für das Management mehrerer einzelner Projekte
ANMERKUNG Das Multiprojektmanagement kann in Form von Programmen oder Portfolios organisiert werden. Dazu gehört insbesondere die Koordinierung mehrerer Projekte bezüglich der Zuordnung gemeinsamer Ressourcen zu den einzelnen Projekten. {Deutsches Institut für Normung. 2009 #35: 10}
In größeren Organisationen kann für die Initiierung eines Projektes ein standardisierter Projektantrag zur Anwendung kommen. Mit Hilfe eines Formulars können wichtige Projektparameter abgefragt werden.
2.3.3 Projektkonkretisierung, die Projektidee wird weiter verfolgt
Sind Initiator und Sponsor unterschiedliche Personen, wird die Zustimmung für die Investition von Ressourcen an finanzielle, personelle und zeitliche Rahmenbedingungen geknüpft werden. Dies wird in vielen Fällen bereits in einem Grobkonzept dokumentiert. Ein Konzept mit der Festlegung der wichtigsten Eckdaten sollte in jedem Fall erstellt werden. Nach diesen grundlegenden Übereinkünften kann sich die Person richten, die damit beauftragt wird, die Idee weiter zu untersuchen.
2.3.4 Dokumente zu Projektkonkretisierung
In „unbürokratischen“ Organisationen wird die Freigabe für die Weiterverfolgung oft nur mündlich erfolgen. Manchmal existiert eine E-Mail oder ein Protokolleintrag eines Meetings, dass jemand bis zu einem bestimmten Zeitpunkt bestimmte Punkte erledigen soll. Es ist jedoch von Vorteil für alle Beteiligten, vor allem für den für das Voranschreiten des Projektes Verantwortlichen, schriftlich die Rahmenbedingungen und Verantwortlichkeiten des Auftrages festzuhalten und bereitzustellen. Je mehr Klarheit besteht, desto besser für den weiteren Verlauf des Projektes.
Before committing significant resources, you must have agreement on what your project should produce, by when, and using what resources. While the brief should have identified the rationale and broad strategy behind a project, the next step is to define the scope of the project – precisely what will be handed over to the end users on completion. {Hobbs 2009 #19: 24}
2.3.5 Projektvorbereitung, Evaluierung
Nun ist ein Verantwortlicher für die ersten Schritte festgelegt. Dies kann der spätere Projektmanager sein. Falls es die Größe und Tragweite des Projektes rechtfertigt, kann hier bereits eine eigene zentrale Datenablage eingerichtet werden, ansonsten kann die allgemeine Ablage des Projektportfoliomanagement verwendet werden. Sollten Arbeitspakete an unterschiedliche Personen aufgeteilt werden und entsprechende Zugriffsberechtigungen und Strukturen einzuhalten sein, ist die Nutzung eines IT Systems notwendig.
Das Risikomanagement beschäftigt sich in dieser frühen Phase mit der Identifikation von sogenannten „Spielverderbern“ {DeMarco 2003 #49: 67} und einer ersten Risikoidentifikation, die zum Beispiel in einem Brainstorming stattfinden kann. Spielverderber sind Risiken, die zu einem Abbruch des Projektes führen.
Erklären Sie Spielverderber zu Projektvoraussetzungen. Vollziehen Sie das Ritual, jedes dieser Risiken auf eine höhere Entscheidungsebene zu verlagern. {DeMarco 2003 #49: 182}
Zur Unterstützung der Erstellung der Risikoliste kann zum Beispiel die „risk breakdown structure“ RBS und der Liste der 5 Kernprojektrisiken von DeMarco herangezogen werden.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-1 Risk Breakdown Structure {Project Management Institute 2008 #56: 280}
Kernrisiken von Softwareprojekten ...
1. inhärent fehlerhafter Zeitplan
2. Inflation der Anforderungen (ausufernde Anforderungen)
3. Mitarbeiterfluktuation
4. Spezifikationskollaps
5. geringe Produktivität {DeMarco 2003 #49: 108-109}
Speziell zu behandeln ist der Spezifikationskollaps. DeMarco empfiehlt dieses Risiko von Projektbeginn an in den Mittelpunkt des Risikomanagements zu stellen.
Kernrisiko 4: Spezifikationskollaps
Das vierte Kernrisiko, der Spezifikationskollaps, unterscheidet sich in seiner Art von den anderen. Er ist eher ein Einzelereignis als ein fortwährendes Problem, es geht dabei um alles oder nichts ..., erweisen sich die Folgen fast immer als fatal. Ein Spezifikationskollaps verzögert Ihr Projekt nicht - er schießt es ab.
Ein Spezifikationskollaps liegt vor, wenn der Verhandlungsprozess scheitert, der bei der Festlegung der Anforderungen zu Projektbeginn im Mittelpunkt steht. {DeMarco 2003 #49: 116}
Eine Zeit lang verschwindet das vertuschte Problem, aber nicht für immer. Es ist zwar möglich, ein Produkt wolkig zu spezifizieren, aber nicht, es wolkig zu entwickeln. Irgendwann muss das aufgeschobene Problem angepackt werden, und der Konflikt flackert erneut auf. {DeMarco 2003 #49: 117}
Die Behandlung dieses Kernrisikos ist ebenfalls recht ungewöhnlich. Wir schlagen vor, dass Sie jedes neue Projekt mit dem feststehenden Risiko der Projekteinstellung versehen bis die Spezifikation klar abgeschlossen ist. Danach schalten Sie das Risiko ab. {DeMarco 2003 #49: 118}
Um ein Projekt gut vorbereiten zu können, müssen als erstes Recherchen über den Bereich des Projektes unternommen werden. Die Informationsquellen können Bücher, Zeitschriften und Internetquellen sein. Spezialisten und Stakeholder aus Fachabteilungen können befragt werden. Wenn bereits ein organisiertes Projektmanagement im Unternehmen installiert ist und die Ergebnisse der Evaluierung früherer, ähnlicher Projekte vorliegen, muss man diese berücksichtigen.
Die Ähnlichkeit von Projekten kann an Metadaten festgemacht werden. Dies sind: in das Projekt involvierte Stakeholder, vom Projekt berührte Themen und Techniken, spezielle verwendete Technologien und Verfahren, Einsatzgebiete, gesetzliche Bestimmungen und andere Umwelteinflüsse. {Vergl. Roberts 2007 #38: 217 ff}
2.3.6 Dokumente der Projektvorbereitung
Das Ziel der Phase ist es, die Grundlage für die Entscheidung des Sponsors vorzubereiten. In einem ersten Brainstorming werden Ideen erfasst. In Arbeitsmeetings werden diese Ideen diskutiert, bewertet und weiter bearbeitet. Es werden Anforderungs- und Risikoanalysen erarbeitet, Ausschreibungen meist mit einem Lastenheft (Aufgabenbeschreibung) erstellt und Angebote eingeholt, Meetings abgehalten und diese entsprechend dokumentiert. Es stellen sich potenziell in Frage kommende Hersteller und Partner vor und präsentieren sich und ihre Produkte. Der Verantwortliche wird versuchen, diese einander gegenüber zu stellen und zu vergleichen. Vor- und Nachteile der einzelnen vorgeschlagenen Lösungen werden ausgearbeitet. Es erfolgt eine Kalkulation und Planung. Ein Zeitplan wird erstellt. Die Präsentation für den Sponsor wird vorbereitet, durchgeführt und daraus resultierende Ergebnisse protokolliert.
Durch das Risikomanagement wird eine erste Risikoliste erzeugt, die während des gesamten Projektverlaufes weiter verfeinert, ergänzt und aktuell gehalten wird. Risiken die nicht eingetreten sind, werden von der Risikoliste gelöscht. Details finden Sie im Abschnitt 2.3.12.3 Risikoliste.
Dies kann in einem iterativen Prozess geschehen oder in einem großen Schritt. Die dabei erzeugten Dokumente sind vor allem dann von Wert, wenn das Projekt scheitert. Die möglichen Fragestellungen in der Zukunft lauten: Warum wurde eine bestimmte Entscheidung getroffen? Warum wurde etwas nicht weiter verfolgt? Ausgehend von diesen Fragestellungen sind die Dokumente zu strukturieren und archivieren.
Zusammengefasst sind die Typen der Dokumente: Anforderungsliste, Risikoliste, Ausschreibung, Lastenheft, Meeting-Protokoll, Präsentation, Produkt- oder Lösungsvergleich, Kalkulation, Zeitplan, Sponsorenpräsentation.
2.3.7 Die Entscheidung für das Projekt
Nun trifft der Sponsor die Entscheidung, ob das Projekt durchgeführt wird. Die Rahmenbedingungen, die zu erreichenden Ziele, der Zeitplan sind abgesteckt und freigegeben.
- Was wird gemacht (Projektziel)?
- Wer wird es machen (Projektleiter und Projektteam, externe Partner)?
- Welches Produkt, welcher Hersteller, welcher Partner?
- Der finanzielle Rahmen
- Leistung und Qualitätsziele
- Der zeitliche Rahmen, Termine
Wesentlich für den Projekterfolg ist es, die Rahmenbedingungen und Projektziele festzulegen und Risiken und Chancen zu identifizieren. Die Ziele beeinflussen sich gegenseitig, wie im „dynamischen Projektdreieck“ schematisch dargestellt:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-2: dynamisches Projektdreieck nach {Peipe 2009 #3,. 69}
Vergleiche dazu auch das „magische Dreieck des Projekterfolges von D.S. Koreimann: Wirtschaftlichkeit, Zielerreichung, Qualität und Zeitdauer eines Projektes als Projektsteuerung {Koreimann 2005 #5: 13}
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-3 Das 'magische Dreieck' des Projekterfolges {Koreimann 2005 #5: 13}
Die Anforderungen oder Projektziele können sich fallweise auch noch in der Realisierungsphase ändern. Dies wirkt sich negativ auf mindestens eine Spitze des dynamischen Projektdreieckes aus. Je später im Projekt die Änderung durchgeführt wird, desto schwerwiegender sind die Auswirkungen. Es ist wichtig auf diesen Sachverhalt ausdrücklich hinzuweisen. Solche Änderungswünsche müssen als Vertragsbestandteile dokumentiert und unterschrieben werden, andernfalls ist die Gefahr groß, dass aus Mehrkosten oder Terminüberschreitungen Rechtsstreitigkeiten folgen.
Das Änderungsmanagement begleitet das Projekt in seiner gesamten Laufzeit um notwendige Änderungen in kontrollierter Form zu managen. Diese Punkte sind auch in der DIN 69901 festgelegt: {Deutsches Institut für Normung. 2009 #35: 6}
Änderung (en: change) durch Änderungsantrag begründete, durch Änderungsentscheidung in Kraft gesetzte und durch Änderungsmitteilung als vollzogen bestätigte Änderung bis dahin gültiger Dokumente (Pläne, Verträge usw.)
Änderungsmanagement (en: change management) Erfassung, Bewertung, Entscheidung, Dokumentation und Steuerung der Umsetzung von Änderungen im Projekt gegenüber der bisher gültigen Planung
ANMERKUNG Die Änderungsgründe können sich z. B. aus dem Vertrags-, Stakeholder- oder Ablaufmanagement ergeben. {Deutsches Institut für Normung. 2009 #35: 6}
Änderungs-Anforderung (ChangeRequest): Mit einer Änderungsanforderung dokumentiert ein Projekt-Stakeholder den Wunsch, dass es eine Änderung in Hinblick auf das Projektergebnis bzw. den Projektablauf gibt. {Deutsches Institut für Normung. 2009 #36: 10}
Dazu ein Zitat aus Tom DeMarcos Buch „Bärentango“. Er reiht die sich ändernden Anforderungen unter die fünf Kernrisiken in IT Projekten.
…Aus Projektsicht kommen solche Veränderungen immer einer Inflation der Anforderungen gleich. Selbst das Entfernen einer bereits entwickelten Funktion stellt eine Art Inflation dar, weil es Zusatzarbeit verursacht. {DeMarco 2003 #49: 112}
Der Rat von Tom DeMarco lautet, Risikomanagement zu betreiben und bei der Planung die Risiken als grafische Darstellung über die statistische Wahrscheinlichkeiten zu berücksichtigen. Er postuliert, sich von der Idee der Festlegung von fixen Terminen zu verabschieden und anstelle dessen, Aussagen mit Berücksichtigung der Unsicherheitsfaktoren über die Fertigstellung zu wagen. Er warnt ausdrücklich davor „aggressive“ Planung zu betreiben und Risiken zu ignorieren.
Risikomanagement (en: risk management) systematische Anwendung von Managementgrundsätzen, -verfahren und -praktiken zwecks Ermittlung des Kontextes sowie Identifikation, Analyse, Bewertung, Steuerung/Bewältigung, Überwachung und Kommunikation von Risiken {Deutsches Institut für Normung. 2009 #35: 19}
Die bei der Erreichung der Projektziele einzuhaltende Rangfolge muss definiert sein. So kann in einem Projekt die oberste Priorität der Termin sein, in einem anderem ist die Einhaltung des Budgets verpflichtend. Wird eine der Zielgrößen geändert, muss ein Ausgleich bei den anderen beiden Zielgrößen geschaffen werden. Die Definition der Rangfolge schafft Manövriermöglichkeit für den Projektmanager. Die Festlegung, dass alle Ziele wie geplant erreicht werden müssen, ist oft nicht realistisch. Es können jedoch als Ausgleich für Unwägbarkeiten in der Zukunft, die Projektrisiken, mögliche Reserven eingeplant werden, die dann bei Bedarf nach einem im Vorfeld spezifizierten Genehmigungslauf freigegeben werden können.
Die Definition der Ziele des „dynamischen Projektdreieck“ ist übergeordnet oder begleitend zu dem vom Auftraggeber vorgegebenen Lastenheft zu verstehen. Eine Möglichkeit besteht darin, sie im Projektauftrag festzulegen.
Zieldefinition (en: scope definition) quantitative und qualitative Festlegung des Projektinhaltes und der einzuhaltenden Realisierungsbedingungen,
z. B. Kosten und Dauer, in Zielmerkmalen mit meist unterschiedlichen Zielgewichten (z. B. Muss- und Kann-Ziele) {Deutsches Institut für Normung. 2009 #35: 19}
2.3.8 Dokumente der Entscheidung
Die Dokumente der Entscheidung für das Projekt sind von größtem Wert. Sie bilden die Basis, auf die im Laufe des Projektes immer referenziert werden wird. Entsprechend müssen diese Dokumente jederzeit zur Verfügung stehen. Es soll einen fixen Referenzpunkt geben, also eine zu einem Zeitpunkt offizielle freigegebene Spezifikationen auf die man sich beziehen kann. Aber es muss auch die Möglichkeit gegeben sein, auf Änderungen zu reagieren und diese Änderungen zu dokumentieren.
Ein Schlagwort in der Literatur zu den Projektzielen lautet „SMART“. SMART steht für spezifisch, messbar, aktuell, realistisch und terminiert {Peipe 2009 #3: 70}
Kurz zusammengefasst: es kann nur gemessen werden, was spezifiziert wurde. Die Spezifikation muss aktuell gehalten werden, die Projektziele müssen realistisch sein und Termine müssen gesetzt sein.
Im englischen Sprachraum ist der Begriff „business case“ üblich, die deutsche Übersetzung lautet Geschäftsfall.
The business case underpins any project because it describes success in terms of measurable benefits. […] Once completed, the business case should be submitted to the portfolio management team to be approved. If they do so, they should also provide the budget requested {Roberts 2007 #38: 134}
Paul Roberts fasst die in dieser Arbeit unter „Dokumente der Entscheidung“ angeführten Inhalte in seinem Buch „Guide to Project Management“ in einer tabellarischen Aufstellung der Inhalte des Business Case zusammen:
What should be included in a business case
Opportunity or problem: a description of the opportunity that has led to the need for what this project is intended to deliver.
Strategic fit: shows what contribution the project will make to the organisation’s strategic direction.
Interdependencies: an analysis that illustrates the way in which this project may affect, or be affected by, others
Success criteria: a set of measures by which to describe a successful project outcome.
Option considered: an overview, with supporting analysis, which describes the alter-natives to the chosen solution. This should include the “do-nothing” option.
Selected option: a complete analysis of the selected option, including the following:
Risks: what are the risks of the venture?
Benefits: what are the merits of the venture?
Costs: what will be the whole-life costs of the venture?
Cost/benefits analysis: how well, and when, will the benefits outweigh the costs?
Deliverables and timescales: what are the key deliverables and their due dates?
Planning assumptions: what assumptions have been made in developing the business case?
Benefits realization plan: how will the benefits be measured and delivered?
Management by objectives: what incentives will be offered (if any) to encourage a successful outcome? {Roberts 2007 #38: 135}
2.3.8.1 Projektauftrag
Der Projektauftrag ist das übergeordnete Dokument. In ihm werden auch die Rahmenbedingungen und Ziele festgelegt.
Projektauftrag (en: project order) Auftrag zur Durchführung eines Projekts oder einer Phase, der mindestens folgende Punkte enthält:
Zielsetzung, erwartete Ergebnisse, Randbedingungen, Verantwortlichkeiten, geplante Ressourcen, übereinstimmende Willensbekundung des Auftraggebers und des Projektverantwortlichen
ANMERKUNG: Zum Anfang eines Projekts (zur Initialisierung) findet man häufig auch den Begriff Projektantrag. Dieser Begriff hat dieselbe Bedeutung wie Projektauftrag für die Initialisierung. {Deutsches Institut für Normung. 2009 #35: 12}
Teil des Projektauftrages ist auch die Beschreibung der erwarteten Vorteile und des Nutzen des Projektes. Sowohl Kosten als auch Nutzen müssen dargestellt sein, um eine Entscheidung treffen zu können.
2.3.8.2 Funktionsdiagramm
Im Funktionsdiagramm werden die Verantwortlichkeiten festgelegt. Dies kann über ein Organigramm mit Funktionsbeschreibung, eine RACI Matrix oder eine AKV Matrix geschehen.
Abkürzungen, die in den folgenden Beispielen verwendet wurden: GF: Geschäftsführer; PS: Projektsponsor; PM: Projektmanager; PK: Projektkoordinator; PT: technischer Projektmitarbeiter; QS: Qualitätssicherung; LA: Lenkungsausschuss
In einem Organigramm werden die hierarchischen Strukturen der Organisation dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-4 Beispiel eines Organigramms
RACI steht für die inhaltliche Zuständigkeit (Responsible), die Verantwortlichkeit (Accountable), Konsultation (Consultable) und Informiertheit (Informed).
Die CAIRO oder RACIO wird die Variante der RACI Matrix genannt, in der auch das explizite Ausschließen von Beteiligten aus dem Informationsfluss festgelegt wird. Das „O“ steht für Omitted – ausgelassen. Anwendung findet dies vor allem, wenn externe Beteiligte nur beschränkten Zugang zu Informationen erhalten sollen.
The RACI is particularly important when the team consists of internal and external resources to ensure clear divisions of roles and expectations {Project Management Institute 2008 #56: 221}
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.2 Beispiel einer RACIO Matrix
Im Gegensatz zur RACI Matrix, wird in der AKV Matrix die Information als Beschreibung der Aufgaben, Kompetenz und Verantwortung in Textform dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2.3 Beispiel einer AKV Matrix
Dadurch, dass im Organigramm die hierarchische Abhängigkeit der Projektbeteiligten dargestellt ist, ist dieses Funktionsdiagramm hilfreich bei Konflikten zwischen Beteiligten im Projekt, die auf einer höheren Ebene gelöst werden müssen. Es ist auf einen Blick klar erkennbar, an welche Person oder Organisationseinheit man sich wenden muss. Auch bei Fragen der Berechtigungen und Berechtigungserteilung ist das Organigramm eine wesentliche Hilfe. Im Gegensatz dazu wird im AKV sehr detailiert die geplante Verteilung von Aufgaben, Kompetenzen und Verantwortung dargestellt. Da die Information in Textform vorliegt, muss man sehr genau darauf achten, dass keine Widersprüche enthalten sind. In der RACI oder RACIO Matrix treten solche Widersprüche klar zu Tage. Es darf in jeder Zeile nur je ein „A“ und je ein „R“ stehen. So ist auf einen Blick klar, wer für die Umsetzung (Responsible) und wer für den Erfolg oder ein eventuelles Scheitern verantwortlich ist (Accountable).
Accountable wird meist mit „verantwortlich“ übersetzt. Dabei wird meist ein „für das Scheitern verantwortlich“ interpretiert. Das greift zu kurz und ist zu negativ. Man sollte das Bild einer „organisatorischen Verantwortung“ im Sinn haben.
Organigramm und RACIO Matrix eignen sich für den schnellen Überblick und die Umsetzung in der Berechtigungsstruktur. Die AKV Matrix kann zusätzliche Informationen darstellen und bei Detailfragen herangezogen werden.
2.3.8.3 Projektplan
Projektplan (en: project plan) Gesamtheit aller im Projekt vorhandenen Pläne {Deutsches Institut für Normung. 2009 #35: 15}
Der Projektplan selbst ist ein lebendes Dokument. Wenn der Projektplan der Entscheidung vorgelegt wird, wird sozusagen ein Schnappschuss des aktuellen Standes gemacht. Mit diesem eingefrorenen Stand wird dann mittels Änderungsmanagement weitergearbeitet.
Project governance report - project plan
This is a living document that describes how the targets set in the business case can be met. The project plan contained in the project governance report is a snapshot taken when the initiation stage is about to be completed. It is used by the project steering group to confirm that they are confident of the plan’s forecasts of timescale, budget and quality and of taking control from the portfolio management team. This snapshot will be retained as a yardstick for measuring progress. It should never be altered because that would undermine the project manager’s ability to manage change. Instead, a copy of the project plan is used to record progress and changes and to show what effect they have had on time, cost and quality expectations. {Roberts 2007 #38: 148}
Der Projektplan besteht aus allen Plänen die zu dem Projekt existieren, dies können sein:
- Projektstrukturplan PSP (englisch: Work breakdown Structure WBS) zur Aufteilung der notwendigen Tätigkeiten in Arbeitspakete
- Netzplan zur Terminplanung und Darstellung der Abhängigkeiten.
- Balkenplan, auch als Gantt-Diagramm bekannt, ist eine alternative Darstellung zum Netzplan. Die Stärke des Balkenplans ist die Darstellung der Dauer der Aktivitäten und hat Einschränkungen bei der Darstellung der Abhängigkeiten.
- Phasenplan
- Steuerungsplan
- Ablaufplan
- Zeitplan
- Meilensteinplan
- Ressourcenplanung
- Qualitätssicherungsplan
- Kommunikationsplan
- Finanzplan
- Beschaffungsplan
Im Einzelnen wird auf diese Dokumente unter „2.3.12.4 Projektplan“ im Detail eingegangen.
2.3.8.4 Verträge
Sind interne oder externe Aufgaben als Aufträge vergeben, existieren dazu Verträge.
Vertragsmanagement (en: contract/administration management) Aufgabengebiet innerhalb des Projektmanagements zu Gestaltung, Abschluss, Fortschreibung, Abwicklung und Verwaltung von Verträgen zur Erreichung des Projektziels einschließlich laufender Dokumentation des gesamten vertragsrelevanten Geschehens {Deutsches Institut für Normung. 2009 #35: 19}
2.3.8.5 Anforderungen
Die Anforderungen werden im Vorfeld der Entscheidung gesammelt, bewertet, gereiht. Wenn das Projekt zur Entscheidung vorgelegt wird, ist bereits geklärt, welche Anforderungen erfüllt werden müssen, welche erfüllt werden sollen und welche in die Kategorie „weitergehende Wünsche“ fallen. In der Literatur wird die Earned-Value Analyse dringend empfohlen. Die Earned-Value Analyse begegnet uns wieder in den Aufgabenlisten: „2.3.12.2 Aufgabenliste mit EVA“
Anforderung (en: requirement) Beschaffenheit, Fähigkeit oder Leistung, die ein Produkt, Prozess oder die am Prozess beteiligte Person erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen {Deutsches Institut für Normung. 2009 #35: 6}
Die Benutzer-Anforderungen werden zum Beispiel in Form von Use Cases erarbeitet. Auch Story Boards eignen sich dazu. Ebenso werden technische und rechtliche Anforderungen erfasst. Die Anforderungen können in Listen übersichtlich verwaltet werden.
Wie bereits unter „2.3.5 Projektvorbereitung, Evaluierung“ diskutiert, gehören Schwierigkeiten bei den Anforderungen zu den Kernrisiken von IT Projekten.
Kernrisiko 2: Inflation der Anforderungen
Die Software, die Sie und Ihre Leute entwickeln, muss letztlich immer in ein bestimmtes Geschäftsumfeld passen. Wir können Ihnen versichern: Dieses Umfeld bleibt während des Entwicklungsprozesses nicht statisch. Es wird sich in einem Tempo ändern, das von seinen Märkten und seiner Innovationsrate diktiert wird... {DeMarco 2003 #49: 112}
2.3.8.6 Risikoliste
Ebenso wie die Anforderungen, müssen auch die Risiken den Entscheidungsträgern zur Kenntnis gebracht werden. Auf die Details wird in „2.3.12.3 Risikoliste“ eingegangen.
2.3.8.7 Weitere Dokumente
Das vom Auftraggeber erstellte Lastenheft
Lastenheft (en: user specification)
vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines (Projekt)Auftrags {Deutsches Institut für Normung. 2009 #35: 9}
In den meisten Fällen wird ein eventueller Auftragnehmer die Erstellung eines Pflichtenheftes erst vornehmen, wenn die prinzipielle Entscheidung für das Projekt auf Seiten des Auftraggebers bereits gefallen ist. In Fällen, in denen der Auftragnehmer eine relativ standardisierte Lösung anbietet, kann es sein, dass er bereits eine erste Version eines Pflichtenheftes vorlegt.
Pflichtenheft (en: functional specification)
vom Auftragnehmer erarbeitete Realisierungsvorgaben auf der Basis des vom Auftraggeber vorgegebenen Lastenheftes {Deutsches Institut für Normung. 2009 #35: 10}
2.3.9 Projektstart
Der Projektleiter wird für Projektmitarbeiter ein „Kick-off Meeting“ vorbereiten, organisieren und durchführen. Eventuell wird er Aufgaben in der Vorbereitung verteilen und deren Ergebnisse wieder zusammenführen müssen. Der Zweck des Kick-off Meetings ist die Weitergabe relevanter Informationen an die Projektmitarbeiter. Es ist ein Informationsmeeting. Hier sollen vor allem die „Leute ins Boot geholt werden“.
Prozess S.5.1 „Kick-off durchführen“
Zweck und Hintergrund: Durch das Kick-off sollten alle Projektbeteiligten noch einmal ein gemeinsames Verständnis bezüglich des Projekts, seinen Zielen, der Projektplanung und den Aufgaben jedes einzelnen Mitarbeiters entwickeln und ein klares Commitment abgeben. Dann kann die eigentliche Realisierung beginnen.
Prozessbeschreibung (Vorgehen): Vorstellung des Projekts mit seinen Zielen, der Planung sowie der vorgesehenen Organisationsform durch den Projektleiter. Abgabe des Commitments durch alle Beteiligten nach erfolgter Aussprache. Gegebenenfalls schon hier erste Maßnahmen zur Teambildung und -entwicklung. Schließlich erfolgt der offizielle Start des Projekts. {Deutsches Institut für Normung. 2009 #34: 41}
2.3.10 Dokumente des Projektstarts
In einem Kick-off Meeting soll die Information bestmöglich für das Zielpublikum vorbereitet werden. Es kann sein, dass Informationen die für Sponsoren und Entscheider formuliert wurden, nun neu aufbereitet und in eine für die Projektmitarbeiter verständlichen Sprache übersetzt werden müssen. Es muss natürlich gewährleistet sein, dass die Aussagen in den unterschiedlichen Dokumenten für die verschiedenen Zielgruppen konsistent gehalten werden. Diese Dokumente können im späteren Projektverlauf noch eine wertvolle Hilfe sein, wenn es darum geht, Fragen zu klären.
Die dafür vorbereiteten Dokumente sind meist Präsentationen und Handouts. Während des Kick-off Meetings können Skizzen zum Beispiel auf einem Flipchart erzeugt werden. Es kann sinnvoll sein, diese digital zu fotografieren und ebenfalls mit Kommentaren versehen zur späteren Referenz abzulegen.
2.3.11 Projektdurchführung
In einem sehr großen Projekt wird die Durchführung in weitere Phasen unterteilt. Diese sollten nicht mit den Projektphasen der Gesamtprojektabwicklung verwechselt werden.
2.3.11.1 Projektdurchführungsphasen
Die Projektdurchführungsphasen werden zum Beispiel im Wasserfall-Modell oder im deutschen V-Modell auch grafisch dargestellt.
Abbildung in dieser Leseprobe nicht enthalten
Abb. 2-5 Wasserfallmodell
Die Pfeile symbolisieren den Weg durch den Prozess. Die gestrichelten Pfeile nach oben die Feedbackschleife zur vorangegangenen Phase, wenn Fehler entdeckt werden.
- Definitionsphase der Projektdurchführung. Es werden die fachlichen Pflichtenhefte aus den anwenderorientierten Lastenheften abgeleitet.
- In der Entwurfsphase der Projektdurchführung wird das fachliche Pflichtenheft in die technische Entwurfsdefinition überführt.
- In der Realisierungsphase wird der technische Entwurf implementiert. Die Arbeit wird mit Entwicklungstests unterstützt und verifiziert.
- In der Testphase können Modul-, Integrations- und Lasttests durchgeführt werden
- Nach Integration und Test auf den Entwicklungs- und Testsystemen folgt in der Produktivfreigabe die Überführung auf das Produktivsystem
In einem dynamischen Umfeld mit dem Bedarf an einer schnell sichtbaren Lösung, ist ein iterativer Ansatz zu wählen. Hier werden die einzelnen Phasen, vor allem deren klar definierte Übergänge und die dabei entstehenden Dokumente untergeordnet behandelt. Um zu einem qualitativ hochwertigen Endprodukt zu gelangen, wird hier ein großer Schwerpunkt auf anwenderorientierte Anforderungsanalyse (Use Cases, Scorecards) und entsprechende Überprüfung durch Tests gelegt. Diese Vorgehensweise wird oft auch als „rapid prototyping“ bezeichnet. Eine gut vermarktete Spielart dieser Methodengruppe ist das „extreme programming“, unter der Abkürzung XP bekannt geworden. Passend zu „extreme programming“ wird „Scrum“ als agile Herangehensweise an das Projektmanagement postuliert. {Pichler 2008 #6}
In der Realität wird meist eine Mischform anzustreben sein. Für die agilen Methoden würde man die kontinuierliche Mitarbeit der Anwender und Fachabteilungen benötigen, die meist nicht gegeben ist.
Ein Projekt mit hinreichender Komplexität, das nur einen Zyklusdurchlauf nach dem V-Modell oder Wasserfallmodell durchläuft, wird in den meisten Fällen an den geänderten Anforderungen der Anwender scheitern. Dieses Vorgehen wäre damit vergleichbar, einem Fußballspieler einen Pass an jenen Punkt zuzuspielen, wo er gerade steht, ohne auf den Spielfluss Rücksicht zu nehmen.
.. Die bewegliche Zielscheibe zu treffen ist ein Problem für alle Beteiligten. Wer plant, in der Zukunft exakt das zu liefern, was die Stakeholder heute zu wollen behaupten, verhält sich wie ein Fußballspieler, der einen Pass dorthin spielt, wo gerade eben noch der Stürmer stand. {DeMarco 2003 #49: 113}
Sowohl die Anzahl der Zyklen, als auch die Dauer ist im Wesentlichen von der Gesamtprojektgröße bestimmt. Es sollen nicht mehr als 8-10 Durchläufe durch die Projektumsetzungsphasen geplant werden, bis die erste Version in produktiver Umgebung eingesetzt wird. Die Dauer eines Durchlaufes sollte sich zwischen 1-3 Monaten bewegen. Es hat sich bewährt, für Anwender erlebbare Funktionalitäten in den jeweiligen Versionen zu implementieren.
2.3.11.2 Teamorganisation
Ein Projektteam kann abhängig von der übergeordneten Organisationsstruktur des Unternehmens oder davon abweichend organisiert sein. Die Mitglieder des Projektteams besetzen ihren Fähigkeiten entsprechende Rollen.
Hier beschreibt Alistair Cockburn unter Berufung auf Larry L. Constantine {Constantine 1995 #64} vier Möglichkeiten der Projektteamstruktur: Hierarchisch (hierarchical), Zufällig (random), Gemeinschaftlich (collaborative) und Synchron (synchronous)
Team Cultures and Subcultures
[...] Cultures and their values can be characterized in many ways. In one characterization (Constantine, 1995), sociologists name four culture types by their communication, power, and decision-making habits [...]
Hierarchical cultures have the traditional top-down chain of command. Typically, older, larger corporations have a hierarchical culture. [...]
Random is the opposite of hierarchical. It indicates a group in which there is little or no central control. [...]
Collaborative groups work by consensus. [...]
Synchronous, or "silent", groups are the opposite of collaborative. They coordinate action without verbal communication, with people performing their roles without attempting to affect the other roles' work styles. [...] {Cockburn 2002 #63: 105}
Interessant ist seine Definition eines synchronen Teams. Die Mitglieder der Gemeinschaft erfüllen automatisch die nun gerade anstehende Rolle. Als Beispiel nennt er die Szene aus dem Film „Witness (1985)“, in der die Mitglieder der Amish Gemeinschaft in einem Tag eine Scheune aufbauen ohne verbale Kommunikation zu benötigen.
Constantine gives two examples of synchronous teamwork. The first comes from a scene in the movie Witness, in which members of the Amish community raise a new barn in a single day, scarcely uttering a word. The second comes from an accident that happened inside a hospital, when a heavy table fell on a person's leg. Without speaking to each other, the people in the room took coordinated action: Two lifted the table, one held the person's hand, one went to call for an X-ray, and one went to get a gurney. {Cockburn 2002 #63: 106}
[...]
- Citation du texte
- Dipl.-Ing. Andreas Zunzer (Auteur), 2009, Sharepoint für Projektmanager, Munich, GRIN Verlag, https://www.grin.com/document/142100
Textes similaires
Devenir un auteur
Commentaires