Aufgaben des Projektmanagements in IT-Projekten

Aus Winfwiki

Hochschule und Studienort:	Fachhochschule für Ökonomie und Management Essen
Fallstudie I	im Rahmen des 5. Semesters zum/r Dipl. Wirtschaftsinformatiker/in
Titel der Arbeit:	Aufgaben des Projektmanagements in IT-Projekten
Betreuer:	Professor Dr. Uwe Kern
Name der Autoren:
Judith Bachmann
Sven Weisenhaus
R. Arning
Eingereicht am:	23. Januar 2009

Inhaltsverzeichnis 1 Einleitung 2 Grundlagen 2.1 Projekt 2.2 IT-Projekt 2.3 Projektmanagement 2.4 IT-Projektmanagement 2.5 Arten von IT-Projekten 3 Aufgaben des Projektmanagements in IT-Projekten 3.1 Planen von IT-Projekten 3.1.1 Projektorganisation 3.1.2 Projektvorgehensmodelle 3.1.3 Projektplanung i.e.S. 3.1.4 Aufwandsschätzung in IT-Projekten 3.2 Risikomanagement 3.2.1 Risikoidentifizierung 3.2.2 Risikoanalyse 3.2.3 Risikopriorisierung 3.2.4 Risikosteuerung 3.2.5 Risikoüberwachung 3.3 Projektkontrolle 3.4 Projektcontrolling 3.5 Projektsteuerung 3.6 Qualitätssicherung 3.6.1 Projektdokumentation 3.6.2 Laufende Berichterstattung 4 Anwendungsbeispiel 4.1 Projektziel 4.2 Projektorganisation 4.3 Projektdokumentation 4.4 Projektkontrolle und -Controlling 4.5 Projektverlauf 5 Schlussbetrachtung 6 Fußnoten 7 Anhänge 7.1 Abkürzungsverzeichnis 7.2 Abbildungsverzeichnis 7.3 Literaturverzeichnis 7.4 Internetquellen

1 Einleitung

Auch mit der Einführung der verschiedenen neuen Studiengänge zum Bachelor oder Master gibt es bis heute keinen Studiengang bzw. keine Ausbildung zum „Manager“. In Ermangelung dessen wählen viele Studenten den Studiengang BWL, wenn sie eine Managerkarriere anstreben.
Es gibt jedoch inzwischen eine fast unüberschaubare Anzahl von Lehrbüchern, die versuchen den Begriff und die Funktionen des Managements näher zu erläutern.
Bücher zum Thema Managen von IT-Projekten gibt es zwar, jedoch ist deren Zahl weitaus geringer als die zum Thema des allgemeinen Managements. Jedoch gerade für IT-Projekte scheint es nötig zu sein, das Thema näher zu erläutern.
Die Globalisierung, der steigende Wettbewerb und die stetigen rasanten Technologieerneuerungen haben den Einsatz der IT in Unternehmen wichtig werden und ansteigen lassen. Viele Unternehmen haben den Wert einer gut strukturierten, funktionierenden IT erkannt und die IT als zentrale Unterstützung ihrer Geschäftsprozesse bereits etabliert. Diese muss kontinuierlich gewartet, angepasst oder erneuert werden. Hierdurch besteht ein großer Bedarf an IT-Projektmanagern, der weiterhin anwächst.
Die vorliegende Fallstudie beschäftigt sich mit den Aufgaben des Projektmanagements in IT-Projekten. Ziel ist es, die Aufgaben aufzuzeigen und Methoden für deren Bewältigung darzustellen.
Das Kapitel 1 stellt die Einleitung dar, welche die Aktualität des Projektmanagements in IT-Projekten erläutert.
Im Kapitel 2 wird die Bedeutung einiger zentraler Begriffe geklärt, um für den weiteren Verlauf der Hausarbeit eine gemeinsame Verständnisbasis zu schaffen. Zudem werden die verschiedenen Arten von IT-Projekten kurz dargestellt.
Im dritten Kapitel wird auf die verschiedenen Aufgaben des Projektmanagements eingegangen. Dazu werden die Besonderheiten bei der Planung von IT-Projekten, dem Risikomanagement, dem Projektcontrolling und der Qualitätssicherung näher betrachtet und erläutert.
Aufbauend auf die theoretischen Erläuterungen der Aufgaben des Projektmanagements werden im vierten Kapitel diese anhand eines Beispiels praktisch dargestellt.
Kapitel 5 schließt die Fallstudie mit einer Schlussbetrachtung ab.

2 Grundlagen

Zunächst werden für den Rahmen der Fallstudie die wichtigsten Begriffe definiert, um ein einheitliches Verständnis zu erreichen. Danach erfolgt eine Einteilung der verschiedenen Arten von IT-Projekte.

2.1 Projekt

Die DIN 69901 Projektmanagement definiert ein Projekt als „Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben oder eine projektspezifische Organisation“^[1].
Zudem können folgende Merkmale zur Definierung eines Projektes zugrunde gelegt werden^[2]:

• Einmaligkeit des Vorhabens
• zeitliche Begrenzung mit festen Start- und Endterminen
• klare Ziele
• Komplexität des Vorhabens
• Einsatz von unterschiedlichen Technikern und Methoden
• Zusammenarbeit von Fachleuten aus verschiedenen Sachgebieten
• neuartige und unbekannte Probleme
• hohes Risiko
• eigenes Budget
• besonderer Druck für die Beteiligten

Einige Quellen definieren ein Projekt anhand weniger als der bisherigen dargestellten Merkmale^[3]:

• Eindeutiges Ziel
• Begrenzt
• Individuell
• hohe Komplexität

Balzert definiert ein Projekt als ein „Vorhaben, das in vorgegebener Zeit und mit beschränkten Aufwand ein eindeutiges Ziel erreichen soll, wobei der genaue Lösungsweg weder vorgegeben noch bekannt ist“^[4].
Demnach wird der Begriff Projekt mit unterschiedlichen vielen Merkmalen und Definitionen versehen, jedoch tauchen dabei einige Merkmale immer wieder auf. Diese sind die Einmaligkeit eines Projektes, dessen begrenzt Laufzeit (Start- und Zieltermin stehen fest) und eindeutig definierte Projektziele.

2.2 IT-Projekt

In IT-Projekten werden Informations- und Kommunikationssysteme entwickelt und haben grundsätzliche die gleichen Merkmale wie die der bereits erwähnten Projektmerkmale. Allerdings besitzen IT-Projekte weitere spezifische Eigenschaften. Bei IT-Projekten ist es ab einem bestimmten Projektstatus sehr problematisch Personalressourcen auszutauschen, da der Integrationsaufwand den Grenznutzen überschreiten. Eine standardisierte Abwicklung von IT-Projekten ist möglich da diese sich in immer wiederkehrende gleichförmige Projektphasen einteilen lassen^[5].
Des Weiteren lassen sich 7 Merkmale für IT-Projekte definieren^[6]:

• Komplexität: Große Softwareprojekte bestehen leicht aus 50 Millionen Zeilen Quellcode. Die Einarbeitung selbst in Teilabschnitte dieser Software dauert mehrere Monate.
• Fehleranfälligkeit: Selbst gut organisierte Testreihen können bei einem komplexen Softwaresystem meist nur Teilbereiche abdecken. Hinzu kommt, dass die Auswirkungen selbst kleiner Fehler in einem Teilbereich der Software zu unvorhergesehen Reaktionen führen können.
• Beeinflussung von Fehlerzuständen: Oftmals lassen sich Fehler erst erkennen, wenn das entsprechende Teilsystem in das Gesamtsystem eingebunden wird.
• Organisatorische Auswirkungen: Immer häufiger verändern IT-Projekte die Organisation in Teilbereichen des Unternehmens. Die Komplexität der Planung und Durchführung der Projekte steigt dadurch an.
• Kommunikation: Anwender, Manager und Entwickler sprechen unterschiedliche Sprachen, benutzen unterschiedliche Fachbegriffe und haben unter Umständen ein unterschiedliches Kommunikationsverhalten.
• junge Technologie: Die Informationstechnologie ist im Unterschied zu anderen Ingenieurwissenschaften eine junge Technologie, die seit ihrem Bestehen eine rasante Entwicklung durchgemacht hat. Bewährte Vorgehensweisen wurden bislang nur in Ansätzen entwickelt.
• Ausbildungsniveau: Es gibt bereits verschiedene Ausbildungsberufe und Studiengänge der Informatik. Jedoch gibt es immer noch eine Reihe von Quereinsteigern in der IT-Branche, die nicht das benötigte Ausbildungsniveau mitbringen und ihre Aufgaben deswegen nicht gut genug ausführen können.

2.3 Projektmanagement

Tätigkeiten, die das ausführende Arbeiten im Projekt möglich machen, werden als Projektmanagement verstanden. Dabei ist die Aufgabe von Projektmanagern das Koordinieren von Abläufen, Aktivitäten, Personen und Ressourcen, allerdings nicht sich mit der Aufgabenerfüllung im Detail zu befassen^[7].
Nach DIN 69901 ist Projektmanagement „die Gesamtheit von Führungsaufgaben, -organisation, -techniken und –mittel für die Abwicklung eines Projekts“^[8].
Der Begriff Projektmanagement wird auch als Führungskonzeption für die "Koordination von Planung, Überwachung und Steuerung bei der Abwicklung fachübergreifender Aufgaben angesehen"^[9].
In Mangold wird Projektmanagement wie folgt veranschaulicht ^[10]: Projektmanagement versucht mit verschiedenen Zutaten die gegeben Projektziele zu erreichen und unpassende "Zutaten auszutauschen oder deren Zusammensetzung zu verändern". Dabei bietet das Projektmanagement "der Leitungsfunktion ein Gesamtkonzept zur Durchführung"^[11] der Aufgaben.
Die Ziele des Projektmanagement sind "das Erreichen der definierten Ziele und die Einhaltung der geplanten Ressourcen (Termine, Mitarbeiter-Kapazitäten und Projekt-Budgets)"^[12].

Projektmanagement kann in drei unterschiedliche Aspekte unterteilt werden: dem institutionellen, dem funktionalen Projektmanagement und der Projektleitung/Projektführung ^[13].
Das institutionelle Projektmanagement ist die Aufbauorganisation eines Projektes. Diese wird unterteilt in Projektbeteiligte, die Projektorganisation, das Informationssystem, das Kommunikationssystem, das Dokumentationssystem und das Sachmittelsystem. Dabei unterstützt das Projektumfeld "Projektunterstützung" die Durchführung und Führung durch institutionalisierte Verfahren und Maßnahmen.
Das funktionale Projektmanagement beschreibt die Ablauforganisation eines Projektes. Die Aufgaben werden in ihrer logischen, mengenmäßigen, räumlichen und zeitlichen Abfolge geplant. Die drei Hauptaufgaben des funktionalen Projektmanagements werden dabei in die Funktionen der Projektplanung, Projektsteuerung und der Projektkontrolle eingeordnet.
Die Projektführung/-leitung wird unterschieden in die Führung, den Gruppenprozess und die Kommunikation.
Projektmanagement ist eine allgemeine, vom Projektgegenstand unabhängige Erklärung der Führungsaufgaben, -organisation, -techniken und -mittel zur Planung Überwachung und Steuerung von Projekten. In der Literatur werden präzise Beschreibungen anhand von bestimmten Projektgegenständen erläutert. Dies weißt darauf hin, dass für eine präzise Erklärung des Projektmanagements der Projektgegenstand näher zu definieren ist und sich das Projektmanagement spezifische Kenntnisse über den Projektgegenstand aneignen muss.

2.4 IT-Projektmanagement

IT-Projekte erfordern vom Projektmanagement Kenntnisse über die Besonderheiten, z.B. Verfahren, Prinzipien oder Techniken und Methoden, die in IT-Projekten eingesetzt werden. Aufgrund dessen liegt dem IT-Projektmanagement das Projektmanagement zu Grunde, ergänzt dieses jedoch um die zum Managen von IT-Projekt benötigten Kenntnisse ^[14]. Damit sind jedoch nicht die IT-technischen Spezialkenntnisse z.B. Programmiersprachenkenntnisse gemeint^[15].
Die Anforderung an IT-Projekte sind in den letzen Jahren stetig gestiegen. Dabei sind neue strategische Anforderungen an das Projektmanagement entstanden. Die Gründe liegen zum einen darin, dass die Anwender von IT-Systemen Erfahrungen und Kenntnisse entwickelt haben, so dass sie diese in neue Systeme mit einfließen lassen möchten, zum anderen werden viele IT-Systeme für die Geschäftsprozessanwicklung der Unternehmen entwickelt oder haben viele Schnittstellen zu diesen. Die Komplexität der IT-Systeme steigt somit an und erfordert vom Projektmanagement und den Projektmitgliedern eine umfassende Betrachtung aller abhängigen Geschäftsabläufe^[16].

2.5 Arten von IT-Projekten

IT-Projekte können anhand ihrer verschiedenen Eigenschaften definieren werden^[17]. Dabei wird nach Projektaufwand, Projektstandort, Technologie, Charakter der Projektziele und der Phasenschwerpunkte unterschieden. Das Projektmanagement muss dabei auf die unterschiedlichen IT-Projekte ausgerichtet werden. Ein Projekt, das innerhalb von 4 Wochen durchgeführt werden soll, ist anders und weniger aufwendig durchzuführen, als ein Projekt, das eine geplante Laufzeit von 2 Jahren hat.
Laut Bruno lassen sich in der Informatik 7 Projektarten festlegen^[18]:

• Entwicklungsprojekte, z.B. Strategie- oder Innovationsprojekte, Eigenentwicklung
• Ausbildungsprojekte
• Organisationsprojekte (Evaluations- und Ausführungsprojekte, z.B. Systemeinführungen)
• Unterstützungsprojekte
• EDV–Projekte
• Wartungsprojekte
• Versuchsprojekte, z.B. Prototypen für spätere komplexe Systeme

Andere Quellen unterteilen IT-Projekte in drei verschiedene Projektarten^[19]:

• Integrationsprojekte erhöhen die Architekturkonformität der Applikationen.
• Erneuerungsprojekte verbessern die Leistungsfähigkeit der IT-Infrastruktur, indem vorhandene Technologien erneuert oder ersetzt werden.
• Erweiterungsprojekte vergrößern das Leistungsspektrum durch Aufnahme neuer Technologien.

Hofmann / Schmidt unterteilen IT-Projekte in vier unterschiedliche Vorhaben^[20]:

• Individualsoftware, Entwicklung, Anpassung, Wartung und Weiterentwicklung von Anwendungssystemen
• Customizing und Einführung von Standardsoftware, Auswahl, Anpassung und Einführung von Standardsoftware, Z.B. ERP-Systeme
• IT-Projekte zur Geschäftsprozessoptimierung, betreffen das ganze Unternehmen
• IT-interne Vorhaben, z.B. Umstellung der IT-Prozesse auf ITIL-Konformität oder die Etablierung des IT-Sicherheitsmanagementprozesses

3 Aufgaben des Projektmanagements in IT-Projekten

Im Folgenden sollen die Schwerpunktaufgaben des Projektmanagements in IT-Projekten, aber auch in anderen Projekten näher betrachtet werden. Das Verständnis, welche Aufgaben explizit dem Projektmanagement zuzuordnen sind, ist je nach dem welche Literatur man zugrunde legt, stark abweichend. Um den Rahmen der Fallstudie zu wahren, wurde an dieser Stelle eine Vorauswahl getroffen und diese auf die nun im Folgenden näher betrachteten Themengebiete beschränkt.

3.1 Planen von IT-Projekten

Eine der wichtigsten Aufgaben des Projektmanagements in IT-Projekten, aber auch bei anderen Projekten, ist die genaue vorausschauende Planung des Projektes. Diese Planung sollte möglichst vor Beginn der eigentlichen Projektarbeit abgeschlossen sein. Allerdings machen unvorhergesehene Komplikationen oder neue, bzw. abgeänderte Anforderungen des Kunden häufig eine Überarbeitung und Korrektur der ursprünglichen Projektplanung erforderlich.
Die Projektplanung umfasst mehrere Schritte. Es ist nicht nur die geeignete Projektorganisation festzulegen, sondern auch das passende Vorgehensmodell für das jeweils vorliegende Projekt zu wählen, die Projektplanung im engeren Sinne durchzuführen und eine Aufwandsschätzung über das gesamte Projektvolumen durchzuführen. Diese Aufgaben werden im Allgemeinen dem Tätigkeitsbereich des Projektmanagements zugeordnet und sind dementsprechend üblicherweise auch von diesem durchzuführen.

3.1.1 Projektorganisation

Es gibt viele, zum Teil recht unterschiedliche Auffassungen darüber, was genau unter Projektorganisation zu verstehen ist bzw. welche Aufgaben in welchem Umfang die Projektorganisation umfasst und beinhaltet. Eine offizielle Beschreibung des Begriffes lautet z.B.: "Projektorganisation ist, entsprechend der DIN 69 901, die Gesamtheit der Organisationseinheiten und der aufbau- und ablauforganisatorischen Regelungen zur Abwicklung eines bestimmten Projektes^[21]." Eine andere Erläuterung bringt dies inhaltlich auf den Punkt: "Die Projektorganisation definiert die Rollen in einem Projekt und deren Berichtswege^[22]." Anders ausgedrückt, herrscht an dieser Stelle Einigkeit darüber, das die Projektorganisation in erster Linie Kommunikations- und Weisungswege sowie Kompetenzen, Verantwortlichkeiten und Zuständigkeitsbereiche, sowie die genauen Aufgaben und Pflichten der einzelnen Organisationseinheiten definiert und diese Struktur in die bereits bestehende Unternehmensorganisation einbindet^[23]. Dies ist die offenbar am weitesten verbreitete Auffassung, die sinngemäß so in der Literatur immer wieder auftaucht. Selbstverständlich gibt es hierzu auch abweichende Ansichten, bei denen z.B. die Aufgaben der Projektorganisation ganz global in Steuerung, Management und Durchführung des Projektes unterteilt werden^[24].

"Eine durchdachte, strukturierte und klare Projektorganisation ist äußerst wichtig für das Gelingen eines Projektes^[26]." So ist es neben der Wahl der Organisationsstruktur ebenfalls sehr wichtig, Rollen zu definieren, die sich in der Projekthierarchie wiederfinden, wie der Projektlenkungsausschuss, der für die Steuerung des Projektes zuständig ist, die Projektleitung, die zuständig für das Management des Projektes ist und dem Projektteam, welches zuständig für die Durchführung des Projektes ist, sowie eine übergeordnete Gesamtprojektleitung^[27] (siehe Abbildung: "Organisation"). An dieser Stelle soll der Fokus auf die aufbau- und ablauforientierte Sicht der Projektorganisation gerichtet werden.
Die am häufigsten genutzten und in der Literatur immer wiederkehrenden Organisationsformen für (IT-)Projekte sind üblicherweise

• die Einfluss- / Stabs-Projektorganisation
• die reine / autonome Projektorganisation
• die Matrixorganisation

sowie deren Mischformen^[28]. Diese Projektorganisationsformen, sowie deren Vor- und Nachteile, sollen im Folgenden kurz vorgestellt werden.

Die Einflussprojektorganisation (siehe Abbildung "Einflussprojektorganisation") wird häufig auch als Stab-Linien-Organisation bezeichnet^[30]. Der Projektleiter hat in dieser Organisationsform eine Stabsstelle inne und betätigt sich als Informationssammler und -verteiler, sowie auch als Projektkoordinator^[31]. Dies bedeutet, das er eine reine Beratungs- und Informationsstelle darstellt und keinerlei direkte Weisungs- und Entscheidungsbefugnisse hat, außer denen, die Vorgesetzte ihm zusprechen. Das ihm unterstellte Projektteam bleibt direkt dem ursprünglichen fachlichen und disziplinarischen Vorgesetzen unterstellt und ausschließlich dieser hat direkte Weisungs- und Entscheidungsbefugnis. Das hat zwar den Vorteil, das die ursprüngliche Organisationsform des Unternehmens weitestgehend unangetastet bleibt, eine Steuerung der Mitarbeiter jedoch nur über den jeweiligen Linienvorgesetzten erfolgen kann und sämtliche Entscheidungen in der Linie getroffen werden^[32]. Durch diese Verbleibung in der ursprünglichen Hierarchie kommt es häufig dazu, das die Projektmitarbeiter sich weiterhin primär für ihre üblichen Aufgaben verantwortlich fühlen und erst nachrangig für die Projektarbeit. Wie auch bei dem "Einlinien-System" zeichnet sich auch die hier vorgestellte "Einflussprojektorganisation" bzw. "Stab-Linien-Organisation" vor allem durch lange Kommunikations- und Weisungswege aus. Jede Kommunikation muss entlang der Linie, das heisst, von ganz oben bis ganz unten (und natürlich auch umgekehrt) über jede einzelne Instanz erfolgen. Dieses System reagiert daher auf unvorhergesehene Situationen nur sehr schwerfällig. Für diese Organisationsform spricht, dass die Installation in die vorhandene Unternehmensstruktur nur einen geringen organisatorischen Eingriff darstellt^[33]. Es wird daher vor allem für Projekte gewählt, bei denen viele bis alle Bereiche und Mitarbeiter involviert und betroffen sind^[34]. In der Praxis wird diese Organisationsform tatsächlich jedoch nur selten genutzt, da ihr Einsatz, auch aufgrund der oben genannten Probleme, lediglich bei kleinen und mittleren Projekten zu brauchbaren Ergebnissen führt^[35].

Bei der reinen Projektorganisation (siehe Abbildung "Reine Projektorganisation") ist der Projektleiter für die Entscheidungen im Projekt zuständig und verantwortlich^[37]. Das Projektteam wird bei dieser Organisationsform in Form einer eigenständigen Organisationseinheit in die bestehende Unternehmensstruktur eingebunden^[38]. Die Projektmitarbeiter werden somit komplett aus der bisherigen Struktur herausgelöst und von ihren bisherigen Aufgaben entbunden, so das sie für die Dauer des Projektes eine komplett eigenständige Organisationseinheit bilden, für die der Projektleiter auch der fachliche und disziplinare Vorgesetzte ist und somit Weisungs- und Entscheidungsbefugnisse erhält^[39]. Diese ausschließliche Ausrichtung auf die Projektarbeit führt dazu, dass die Identifikation mit dem Projekt wesentlich höher ist als z. B. bei der Einflussprojektorganisation. Durch die Weisungs- und Entscheidungsbefugnisse des Projektleiters kann das System viel schneller und effektiver reagieren, als es bei anderen Organisationsformen der Fall ist. Es kann jedoch, vor allem bei langen Projektlaufzeiten leicht zu Schwierigkeiten bei der Reintegration der Projektmitarbeiter in die ursprüngliche Unternehmenshierarchie kommen^[40].

Die Matrixorganisation (siehe Abbildung "Matrixorganisation") bildet eine Mischform aus Einflussprojektorganisation und reiner Projektorganisation und versucht so, die Vorteile beider Organisationsformen miteinander zu vereinen^[42]. Bei dieser Organisationsform ist es so, dass jede Instanz bzw. jeder Projektmitarbeiter zwei Vorgesetzten unterstellt ist. Die Mitarbeiter verbleiben also in der ursprünglichen Hierarchie, bekommen jedoch für die jeweilige Projektarbeit einen zweiten, explizit hierfür zuständigen Vorgesetzten. Die Weisungs- und Entscheidungsbefugnisse sind hierbei zwischen dem jeweiligen Projektleiter und dem Vorgesetzten aus dem Fachbereich aufgeteilt^[43]. Dies sieht in der Praxis so aus, das die Mitarbeiter fachlich zur Mitarbeit an dem Projekt dem Projektleiter unterstellt werden, personell jedoch weiterhin dem Linienvorgesetzten unterstellt sind^[44]. Diese Überschneidung der Kompetenzen führt natürlich leicht zu Konflikten, wenn es durch die uneinheitliche Weisungsbefugnis zu Widersprüchen kommt. Dies ist zwar gewollt und soll konstruktiv und kooperationsfördernd wirken, führt oftmals allerdings eher zu erheblicher Demotivation des Projektteams^[45]. Ein weiteres Problem ist, dass bei der Matrixorganisation oft mehrere Vorgesetzte, bzw. mehrere Projektleiter um die knappen (Personal-)Kapazitäten aus den einzelnen Fachabteilungen konkurrieren^[46], was ein hohes Maß an Kompromiss-, Konflikt- und Führungskompetenz von den beteiligten Führungskräften, also den Projektleitern und den personellen Vorgesetzten, erfordert. Der Einsatz von Matrixorganisationen ist trotzdem immer dann zu empfehlen, wenn zwar die Kompetenzen und Erfahrungen mehrerer Mitarbeiter aus mehreren Abteilungen benötigt werden, dies aber nur teilzeitlich oder wenn mehrere Projekte (mit diesen Mitarbeitern) parallel durchgeführt werden sollen^[47].

3.1.2 Projektvorgehensmodelle

Wie bereits an anderer Stelle erwähnt, bei jedem IT-Projekt das am besten passende Vorgehensmodell zu wählen. "Vorgehensmodelle für die Projektplanung, -abwicklung und -kontrolle werden genutzt, um systematisch ein IT-Projekt in vordefinierten Phasen durchzuführen^[48]." Das Vorgehensmodell definiert die generelle Herangehensweise an das Projekt, den grundsätzlichen Ablauf des Projektes und die Vorgehensweise in den einzelnen Projektphasen. Genauer gesagt, werden in der Regel die Projektphasen, Aktivitäten, Meilensteine und Meilensteinergebnisse des durchzuführenden Projektes von vorneherein durch das gewählte Vorgehensmodell definiert^[49].
Eine "Projektphase" ist in der Literatur definiert als "[...]ein zeitlicher Abschnitt des Projektablaufs, der sachlich von anderen Abschnitten getrennt ist (z.B. Konzeptionsphase). Vorgehensmodelle bestehen aus verschiedenen Projektphasen ^[50]." Diese Phasen können sequentiell aufeinander folgen, aber auch parallel zueinander ablaufen oder sich sogar überschneiden. Die Standardisierung der einzelnen Phasen und deren Verknüpfung zu einem logischen Vorgehensmodell erleichtert das Vorgehen auch für unerfahrene Projektleiter und -mitarbeiter, da der "rote Faden" und der genaue Ablauf leicht erkennbar ist ^[51]. Hier ein allgemein gehaltenes Beispiel für die Abfolge der einzelnen Projektphasen^[52]:

• erste Studien (Vorausgehende Bewertung konzeptioneller Möglichkeiten)
• Konzeptionierung und Untersuchung von Machbarkeit und Tauglichkeit
• Detaillierte Lösungsentwürfe (Konstruktion, Teilbearbeitung)
• Vergabe (Ausschreibung, Beschaffung, Verträge)
• Ausführung (Implementierung, Herstellung, Lieferung, Realisierung)
• Inbetriebnahme, Übergabe und Übernahme / Abnahmen und Projektabschluss

Als "Aktivitäten" werden im Allgemeinen die Tätigkeiten während einer Phase bezeichnet, die innerhalb dieser Projektphase ausgeführt werden müssen, um die gewünschten, zu Beginn der jeweiligen Phase definierten, Teilergebnisse erzielen zu können^[53]. Mit "Meilensteinen" wird der Zeitpunkt zum Ende einer Phase des Projektes und somit auch der Beginn der darauf folgenden Phase definiert. Zu diesen Zeitpunkten müssen üblicherweise zu Beginn der jeweiligen Phase bestimmte Aktivitäten abgeschlossen sein und entsprechende Ergebnisse vorliegen. Abweichend können Meilensteine auch während einer laufenden Projektphase eingesetzt werden, um Fertigstellungstermine für ein oder mehrere Sachziele festzulegen^[54]. Liegt als Resultat eines solchen Meilensteins ein entsprechendes Sachziel (oder mehrere) vor, spricht man von einem so genannten "Meilensteinergebnis". Diese Meilensteinergebnisse werden anhand von Aktivitäten erzeugt. Beispiele für typische Meilensteinergebnisse sind^[55]:

• kundenseitig erarbeitetes Lastenheft
• vom Projektlenkungsausschuss verabschiedetes Pflichtenheft
• Bericht des Prüfausschusses über Test eines Prototyps
• Patentrecherche
• von Behörde genehmigter Bauplan
• Marktstudie über Absatzchancen eines derzeit in der Entwicklung befindlichen Produktes
• überarbeiteter Projektstrukturplan / Terminplan / ...
• u.v.m

Oftmals werden Meilensteinergebnisse durch das gewählte Vorgehensmodell definiert und somit dem Projektleiter durch dieses vorgegeben. Durch diese Vorgaben wird das Vorgehen und der Ablauf des Projektes von vorneherein strukturiert, was dem Projektleiter einen großen Teil an Planungsarbeit maßgeblich erleichtert.

Es ist an dieser Stelle bereits absehbar, dass das einmal gewählte Vorgehensmodell starken Einfluss auf das gesamte Projekt nimmt und daher sehr sorgfältig ausgewählt werden muss. Gerade im IT-Bereich spielt das Vorgehensmodell eine große Rolle, da mitunter auch Vorgehensweisen für die technische Entwicklung z.B. der gewünschten Software definiert werden. Dies wird an späterer Stelle noch genauer betrachtet.
Als Hilfestellung für die Entscheidungsfindung werden in der Literatur verschiedenste Kriterien angeboten. Einige Kriterien für die Auswahl eines geeigneten Vorgehensmodells können z.B. die folgenden Punkte darstellen^[56]:

• die Anpassung des Modells an die Erfordernisse, Gegebenheiten und Besonderheiten des Unternehmens
• die Akzeptanz des Modells bei den am Projekt beteiligten Mitarbeitern
• der Kenntnisstand der Beteiligten bzgl. der Arbeitsweise mit dem jeweiligen Vorgehensmodell (ggf. Schulung der Mitarbeiter)
• der Komplexitätsgrad des Modells (nicht zu trivial, aber auch nicht zu akademisch)
• es muss nicht nur die Möglichkeit der Weiterentwicklung des Modells bestehen, sondern die aktive Teilnehme aller Mitarbeiter an der Weiterentwicklung sollte von der Unternehmensstruktur gefördert werden
• das gewählte Vorgehensmodell muss an die Besonderheiten des betreffenden Projektes anpassbar sein

Diese Liste kann selbstverständlich je nach Unternehmens- und Projektsituation wesentlich länger, aber auch kürzer ausfallen.
Im Allgemeinen wird zwischen drei möglichen Arten von Vorgehensmodellen unterschieden:

• den konzeptionellen Vorgehensmodellen,
• den evolutionären Vorgehensmodellen und
• den inkrementellen Vorgehensmodellen.

Konzeptionelle Vorgehensmodelle zeichnen sich dadurch aus, dass die jeweiligen Phasen des Projektes sequenziell aufeinander folgen und in dieser entsprechenden Reihenfolge "abgearbeitet" werden^[57]. Hierbei gilt, das mit der Bearbeitung und Durchführung einer neuen Phase immer erst dann begonnen wird, wenn die vorherige Phase tatsächlich abgeschlossen ist. Ein "zurückspringen" in die vorherige, bereits abgeschlossene Phase ist hierbei nicht vorgesehen^[58]. Beispiele für konzeptionelle Vorgehensmodelle sind das Wasserfallmodell - als wohl bekanntestes Projekt-Vorgehensmodell - und das so genannte V-Modell. Diese Vorgehensmodelle haben allerdings auch Nachteile, die nicht außer Acht gelassen werden dürfen. Sie führen mitunter dazu, dass der Kunde oft lange auf das geforderte Projektergebnis (in IT-Projekten z.B. die letztlich einsatzfähige Software) warten muss und dieses erst bewerten und zusätzliche Anforderungen oder auch Kritik äußern kann, wenn das System bereits im laufenden Betrieb eingesetzt wird^[59].

Diese Vorgehensweise soll nun am Beispiel des Wasserfallmodells erläutert werden (siehe Abbildung "Wasserfallmodell"). Nach dem Wasserfallmodell soll eine Software in mehreren, festgelegten Phasen entwickelt werden, die strikt sequentiell durchlaufen werden^[61]. Solche Modelle werden häufig auch als "dokumentgetrieben" bezeichnet, da am Ende jeder Phase, also bei jedem Meilenstein genau definierte Dokumente vorliegen müssen^[62]. Zu Beginn spezifiziert der Kunde die Anforderungen und bekommt dann das Softwareprodukt erst wieder zu sehen, wenn es praktisch fertig zum Probebetrieb ausgeliefert wird, somit ist er nur in die sehr frühen und in die sehr späten Phasen eingebunden^[63]. Er hat keinerlei Möglichkeit, Kritik zu äußern oder Anforderungen zu ändern oder zu erweitern. Die einzelnen Phasen werden, wie bereits erläutert, strikt nacheinander abgearbeitet. Es ist zwar möglich, zwecks Nachbesserung zu Beginn einer Phase in die vorherige (abgeschlossene) Phase "zurückzuspringen", weitere Rücksprünge über mehrere Phasen sind jedoch nicht vorgesehen^[64]. Vorteilhaft beim Wasserfallmodell ist die klar strukturierte, vorgegebene Vorgehensweise, die durch diese konkreten Vorgaben leicht nachvollziehbar und durchführbar wird, auch für eher unerfahrenen Projektleiter und -mitarbeiter. Nachteilig sind die typischen Probleme konzeptioneller Vorgehensmodelle: Der Kunde bekommt das Produkt erst zu Gesicht, wenn es praktisch schon fertig ist. Sollten Anforderungen vergessen oder falsch interpretiert worden sein, wird dies oftmals erst ganz am Ende des Projektes - und somit viel zu spät - festgestellt.

Evolutionäre Vorgehensmodelle berücksichtigen die Nachteile der konzeptionellen Modelle und versuchen diese zu verhindern, indem hierbei zuerst die Kernfunktionen der gewünschten Software entwickelt werden, welche dann stufenweise in verschiedenen Versionen weiterentwickelt werden^[65]. Der Kunde sieht somit schnell bewertbare Ergebnisse und kann zusätzliche Anforderungen und Änderungswünsche frühzeitig äußern. Auch den Entwicklern kommt diese Vorgehensweise zugute, da Erfahrungen aus dem laufenden Betrieb der vorherigen Versionen auf die Entwicklung der darauf folgenden adaptiert werden können. Allerdings können auf diese Weise natürlich auch leicht nicht erkannte grundsätzliche Probleme der Ausgangsversion "mitdurchgeschleppt" werden^[66]. Kritiker bezeichnen diese Vorgehensweise daher oftmals auch als "Bananenprinzip", da hierbei das Produkt quasi grün ausgeliefert und erst beim Kunden ausgereift wird^[67].

Ein Beispiel für evolutionäre Vorgehensmodell ist das so genannte Prototyping.
Diese Vorgehensweise soll nun anhand des so genannten "Wegwerf-Prototyping" als Sonderform des "Prototypings" kurz erläutert werden. Hierbei ist es so, dass in der Definitionsphase des Projektes ein Prototyp entwickelt wird, der dem Projektteam dazu dienen soll, in Zusammenarbeit mit dem Kunden die Anforderungen und verschiedenen Realisierungsansätze zu entwickeln und abzustimmen^[68]. Der Prototyp wird "quick and dirty", das bedeutet schnell und grob, also unsauber entwickelt und muss in jedem Fall weggeworfen werden, sobald er seinen Sinn erfüllt hat. Dies soll verhindern, das solche "quick and dirty"-Software weiterverwendet wird, auch nicht in Bruchstücken. Solche Prototypen kommen üblicherweise in den ersten Phasen eines Projektes zur Anwendung. Theoretisch spricht aber nichts dagegen, sie (sofern es sinnvoll ist) auch in späteren Projektphasen noch einmal einzusetzen, zum Beispiel um zu späten Zeitpunkten nachgereichte oder geänderte Anforderungen ebenfalls entsprechend zu verdeutlichen und mit dem Kunden und dem Projektteam zu klären. Das Prototyping wird natürlich am häufigsten in IT-Projekten angewandt, da es für andere Projektarten, die sich nicht mit der Entwicklung von Software befassen, kaum nutzbar ist.

Bei inkrementellen Vorgehensmodellen werden, im Gegensatz zu konzeptionellen Vorgehensmodellen, die einzelnen Projektphasen nicht strikt sequentiell nacheinander durchlaufen, sondern in Form eines Zyklus immer wieder, solange, bis das gewünschte Endergebnis erreicht worden ist^[69]. Dies führt dazu, dass die gelieferte Funktionalität solange stufenweise wächst, bis schließlich das angestrebte Gesamtsystem realisiert ist^[70]. Diese Vorgehensweise eignet sich vor allem für langfristige und sehr umfangreiche Projekte, deren Zielanforderungen während der Durchführung geändert werden. Ziel ist es auch bei inkrementellen Vorgehensmodellen, dem Kunden bereits nach möglichst kurzer Entwicklungszeit ein (Teil-)System zu liefern, welches schon einen Teil der gestellten Anforderungen erfüllt^[71]. Generell geht es, ähnlich wie bei der evolutionären Vorgehensweise, auch bei der inkrementellen darum, dass ein "Grundgerüst" möglichst früh aufgestellt und dem Kunden vorgestellt wird. Dieses wird dann solange weiterentwickelt, bis das fertige Endprodukt letztlich alle Kundenanforderungen erfüllt. Die Trennung von inkrementellen und evolutionären Vorgehensmodellen ist nicht immer eindeutig, teilweise wird in der Literatur auch gar keine Trennung vorgenommen^[72]. Ein Beispiel für die inkrementelle Vorgehensweise liefert das Spiralmodell, das genau diese Elemente beinhaltet. Festgelegte Phasen werden immer wieder durchlaufen, wie in einer Spirale, bis das Ergebnis die gewünschten Anforderungen erfüllt. Das Spiralmodell wird in der Literatur auch als "Metamodell" bezeichnet, da bei diesem Vorgehensmodell "[...]der Gedanke im Vordergrund steht, das Entwicklungsrisiko zu minimieren^[73]".

3.1.3 Projektplanung i.e.S.

Das zugrunde liegende Problem in der Planung von IT-Projekten spiegelt sich im so genannten "magischen Dreieck" wieder (siehe Abbildung "magisches Dreieck"). Hier sieht man, dass die Ausprägungen der drei Zielfaktoren, nämlich Zeit, Kosten und Qualität, an den jeweils entgegengesetzten Spitzen des Dreiecks liegen. Dies soll verdeutlichen, das eine Fokussierung auf einen dieser Faktoren stets zu Lasten der übrigen Faktoren geht. "Beispielsweise erfordert eine Erhöhung von Leistung/Qualität mehr Mitarbeitereinsatz. Dadurch wächst der Zeitaufwand. Bei gleich bleibender Mitarbeiterzahl verlängert sich auch die Projektlaufzeit. Außerdem steigen die Projektkosten als Folge des höheren Zeiteinsatzes^[75]." Dieses Dreieck wird teilweise zum "magischen Fünfeck" erweitert, bei dem die Faktoren "Beteiligte" und "Methoden / Tools" zwei weitere Ecken des Fünfecks darstellen^[76].

In diesem Teil der Arbeit soll nun die Projektplanung im engeren Sinne näher betrachtet werden. Um ein (IT-)Projekt unter Berücksichtigung der oben genannten Problematik sauber planen zu können, benötigt die Projektleitung "[...] eine Werkzeugkiste zur Planung, Steuerung und Überwachung, um ein Projekt mit Rücksicht auf technische und wirtschaftliche Aspekte

• in einer vorgegebenen Zeit (= Termine),
• mit beschränktem Budget [...], sowie
• unter Einhaltung der Leistungsziele [...]

darstellen zu können[...]^[77]". Die Problematik der Aufwandsschätzung (Planung des Budgets) wird unter Punkt 3.1.4 "Aufwandsschätzung in IT-Projekten" näher betrachtet. Somit sind an dieser Stelle die beiden verbleibenden Punkte bzgl. des Zeitrahmens und der Projektziele näher zu betrachten. "In Projekten gilt es, die vier Ziele "Sachziel", "Terminziel", "Kostenziel" und "Qualitätsziel" klar zu definieren und jederzeit im Auge zu behalten^[78]." Diese Projektziele werden üblicherweise ganz zu Anfang, noch vor Beginn der eigentlichen Projektarbeit, definiert. An dieser Stelle erfolgt, wie bereits erwähnt, eine Fokussierung auf das reine Sachziel und ein kurzer Ausblick auf die Terminzielplanung, sowie die Ressourcenplanung eines Projektes, da die anderen beiden Zielarten bereits an anderen Stellen dieser Arbeit betrachtet werden. Das Sachziel eines Projektes wird im Allgemeinen definiert durch^[79]:

• eine genaue Analyse des fachlichen Umfelds
• exakte Dokumentation der Kundenanforderungen (Lastenheft, Pflichtenheft)

und im Anschluss überwacht z.B. durch^[80]:

• fachliche Reviews,
• Prototyping,
• intensives Testen,
• Status - Reports,
• Statusmeetings.

Status-Reports dienen hierbei, ebenso wie Statusmeetings, der Ermittlung und Überwachung des derzeitigen Projektstandes, um Probleme und Engpässe gegebenenfalls frühzeitig identifizieren und eskalieren zu können.
Fachliche Reviews von externen Personen sollen dazu dienen, den Projekterfolg objektiv überprüfen zu lassen.
Der Einsatz von Prototypen wird unter 3.1.2 "Projektvorgehensmodelle" ausführlich erläutert, Sinn und Zweck intensiven Testens der entwickelten Software wird hier nicht näher betrachtet, da es absolut selbsterklärend sein sollte.
Eine genaue Analyse des Projektumfelds muss erfolgen, um die Anforderungen des Auftraggebers korrekt erfassen und sinnvoll umsetzen zu können^[81]. Diese Anforderungen und die daraus entwickelten Sachziele des Projekts werden im Lasten- und im Pflichtenheft detailliert festgehalten^[82]. "DIN 69 905 definiert beide Begriffe: Unter einem Lastenheft versteht man "die Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers". Es macht Aussagen darüber, was zu erarbeiten ist und wofür. Das Pflichtenheft enthält die "vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des Lastenhefts".^[83]" Kurz gesagt: "Mit Hilfe eines Pflichtenheftes werden Anforderungen [...] schriftlich fixiert^[84]." Lasten- und Pflichtenhefte sind demnach Dokumente, die in keiner Projektplanung fehlen dürfen. Beide müssen, sobald sie fertig ausgearbeitet sind, sowohl vom Auftraggeber als auch vom Auftragnehmer genehmigt werden, um zu gewährleisten, dass sowohl die Anforderungen des Kunden, als auch die zu liefernde Leistung des Auftragnehmers richtig verstanden und abgestimmt wurden. "Das Pflichtenheft stellt die fachliche Basis für das gesamte Projekt dar [...]^[85]" und bildet die Grundlage, auf der das Projekt letztendlich auch vom Kunden abgenommen wird.
Pflichten- und Lastenheft dienen jedoch nicht nur als Vertragsgrundlage, sondern auch für die Terminplanung eines Projektes: "Aufgabe eines Pflichtenheftes ist es, die Leistungen und Termine [...] schriftlich zu fixieren^[86]." Die Terminplanung eines Projektes ist also (auch) durch das Pflichtenheft vorgegeben. Die Terminplanung muss mit dem verwendeten Vorgehensmodell (vgl. 3.1.2 "Projektvorgehensmodelle") abgestimmt werden, da grundsätzlich die zu durchlaufenden Projektphasen, Aktivitäten und Meilensteine definiert werden. Die Terminplanung eines Projektes definiert nun, in welchen zeitlichen Rahmen Phasen durchlaufen werden sollen, wann Aktivitäten abgeschlossen sein und (Meilenstein-) Ergebnisse vorliegen müssen. Da es sehr schwer ist, eine Terminplanung "per Hand" zu erarbeiten und graphisch darzustellen, bietet es sich an dafür eines der gängigen hierfür entwickelten Software-Tools, wie z.B. "Project" von Microsoft, zu verwenden.
"Neben der Planung der Arbeitspakete ist es mindestens genauso wichtig, den Einsatz der benötigten Ressourcen einzuplanen^[87]." Bei IT-Projekten fällt die Ressourcenplanung meistens (zumindest zum größten Teil) mit der Aufwandsschätzung zusammen, da es sich hierbei in der Regel um die Entwicklung und Implementierung von Software-Systemen handelt. Die dazu hauptsächlich benötigte Ressource ist Arbeitskraft, welche als Berechnung aus Arbeitsstunden der eingesetzten Mitarbeiter bereits in die Schätzung des Projektaufwandes mit eingeht. Der Vollständigkeit halber sollte dieser Aspekt der Projektplanung jedoch ebenfalls hier erwähnt werden.
Abschließend lässt sich sagen, dass die Projektplanung im engeren Sinne die folgenden Ziele verfolgt^[88]:

• Bestimmung des Endtermins des Projektes
• Rechtzeitiges Erkennen und Eskalieren von Terminabweichungen
• Planung und Überwachung von Zulieferterminen
• Verzahnung mit anderen Projekten
• Meilensteinplanung
• Planung und effektive Nutzung der verfügbaren Ressourcen
• Bestimmung und Überwachung des Projektaufwands

3.1.4 Aufwandsschätzung in IT-Projekten

Die Aufwandsschätzung in IT-Projekten zeichnet sich, wie die Praxis zeigt, im Gegensatz zu anderen Projekten vor allem dadurch aus, dass das geschätzte Budget oftmals deutlich überschritten wird^[89]. Ein weiterer Aspekt, der die Aufwandsschätzung von IT-Projekten von der Aufwandsschätzung in anderen Projekten abgrenzt besteht darin, dass es sich bei IT-Projekten in erster Linie um die Entwicklung und Implementierung von Software-Produkten handelt. Dies sind "Produkte", die quasi aus reiner "Denkleistung" der Mitarbeiter entstehen. Hierbei sind also dementsprechend die einzigen verwendeten Ressourcen - und somit die einstigen Faktoren, die bei der Aufwandsschätzung berücksichtigt werden müssen - die Arbeitskraft der Mitarbeiter, also das Humankapital. Dieser Aufwand wird üblicherweise in Mitarbeiterstunden berechnet, also der Stunden, die ein Mitarbeiter mit der Arbeit im Projekt verbracht hat. Diese Reduzierung der zu betrachtenden Ressourcen führt dazu, das die Aufwandsschätzung sehr geradlinig und im Verhältnis zu anderen Projekten natürlich auch einfacher durchzuführen ist.
Eine Aufwandsschätzung wird üblicherweise erstmals in der Initialisierungsphase, also ganz zu Anfang des Projektes durchgeführt, aber auch immer wieder erneut während des laufenden Projektes. Der Grad der Genauigkeit der Aufwandsschätzung ist stark vom Zeitpunkt der Schätzung abhängig. Je weiter das Projekt fortgeschritten ist, desto genauer werden die Schätzungen^[90]. Die Aufwandsschätzung in Projekten dient vor allem den Zwecken

• der Kalkulation der Projektkosten und
• der Planung der Projektlaufzeit

und basiert in der Regel auf dem anhand der Analyse der Kundenwünsche erstellten Pflichtenheft^[91]. (Das Pflichtenheft wurde ebenso wie das Lastenheft unter dem Punkt "3.1.3 Projektplanung i.e.S." erläutert.)
Problematisch ist hierbei jedoch, dass der Schätzung des Aufwands oftmals nicht tatsächliche Daten zugrunde liegen, sondern eher die Höhe der Investitionsbereitschaft des Kunden: Kann der Anbieter nicht zum gewünschten Preis liefern, verliert er das Projekt an die Konkurrenz^[92]. In solchen Situation ist eine Überschreitung des Budgets in der Regel praktisch vorprogrammiert. Hat der Kunde zum Zeitpunkt der Auftragsvergabe eine solche "schönkalkulierte" und auf den Vertrieb des Produktes ausgerichtete Aufwandsschätzung erhalten, wird er unter Umständen auf diesen Zahlen bestehen und nicht bereit sein, den zusätzlichen Aufwand zu tragen. Dies bedeutet, dass im Endeffekt der Anbieter selbst für die Budgetüberschreitung aufkommen muss und letztendlich draufzahlt. Wünschenswert wäre es daher, dass der Vertrag erst nach Abschluss einer möglichst genauen Aufwandsschätzung abgeschlossen wird^[93]. Bei der Aufwandsschätzung sollten folgende Aspekte beachtet werden^[94]:

• Voraussetzung, um eine Schätzung überhaupt durchführen zu können, ist das Vorhandensein möglichst genauer Beschreibungen der Anforderungen (s.o., zum Beispiel anhand des Pflichtenheftes)
• der für die Schätzung benötigte Zeitrahmen muss zur Verfügung gestellt werden
• die Aufwandsschätzung sollte von mehreren Personen durchgeführt werden, nicht von einem Mitarbeiter allein
• das der Aufwandsschätzung zugrunde liegende Schätzverfahren ist zu beschreiben oder zumindest auf die entsprechende Beschreibung zu referenzieren

Bei der Aufwandsschätzung in IT-Projekten sind in jedem Fall die folgenden, praktisch in jedem Projekt auftretenden Aktivitäten - bzw. deren Aufwände - zu berücksichtigen^[95]:

• Projektmanagement (inkl. Projektsitzungen)
• Qualitätsmanagement (inkl. Tests)
• Konfigurationsmanagement
• Änderungswesen
• Erstellung der notwendigen Dokumentation (technisches Handbuch, Benutzerhandbuch)
• Vorbereitung der Entwicklungsumgebung
• Vorbereitung der Testumgebung
• Abnahmevorbereitungen
• Begleiten der Abnahme

Am sinnvollsten ist es, zur Durchführung der Aufwandsschätzung unterschiedliche Schätzverfahren zu nutzen, da der separate Einsatz lediglich einer einzelnen Schätzmethode zur Ermittlung des zu erwartenden Aufwandes keine zuverlässige Schätzung erlaubt und somit nicht sehr sinnvoll ist ^[96]. Zu beachten ist, dass es sich bei jeder einzelnen Form und jeder noch so guten und praktikablen Methode der Aufwandsschätzung letztendlich doch nur um eine Schätzung handelt^[97]. Genaue Aussagen über den Aufwand eines Projekts können tatsächlich erst getroffen werden, wenn das Projekt läuft, bzw. für den bereits in der Vergangenheit liegenden Teil des Projektes. Verschiedene Methoden zur Aufwandsschätzung können untergliedert werden in^[98]

• Vergleichsmethoden (z.B.: Analogiemethode, Relationsmethode)
• algorithmische Methoden (z.B. Gewichtungsmethode, Stichprobenmethode)
• Kennzahlenmethoden (z.B.: Multiplikatorenmethode, Prozentsatzmethode)

Vergleichsmethoden (in der Literatur auch "empirische Methoden" genannt) basieren nicht auf mathematischen Vorgehensweisen, sondern gründen (zumindest teilweise) auf Erfahrungswerten der tatsächlich angefallenen Aufwände in vorherigen Projekten, die Ähnlichkeiten und Parallelen zu dem aktuell vorliegenden Projekt aufwiesen^[99].
Algorithmische Methoden versuchen, den Projektaufwand rein mathematisch mit Hilfe einer Formel zu berechnen, die wiederum auf den Erhebungen der Aufwände bereits abgeschlossener Projekte basieren^[100]. Auch wenn dies nicht immer reibungslos funktioniert, haben diese Methoden dennoch nicht außer Acht zu lassende Vorteile, wie z.B. Strukturierung, gute Dokumentation, Reproduzierbarkeit, Praxiserprobung, und Lerneffekt.^[101]
Bei Kennzahlenmethoden schließlich gibt es zwei alternative Unterscheidungsmöglichkeiten. Im Rahmen der Multiplikatorenmethode einerseits wird auf der Basis von Leistungseinheiten auf den Gesamtaufwand des Projektes geschlossen, während bei der Prozentsatzmethode andererseits die Aufwände der folgenden Projektphasen unter Berücksichtigung des Aufwandes der vorhergehenden Phase berechnet werden^[102].
Basierend auf einem oder mehreren dieser Aufwandsschätzungsmethoden wurden verschiedene, in der Praxis genutzte Schätzverfahren entwickelt^[103]. An dieser Stelle sollen nur die wohl gängigsten und bekanntesten Verfahren genannt werden^[104]:

• Function-Point-Verfahren
• Object-Point-Verfahren
• COCOMO (Constructive-Cost-Model)
• SHELL-Verfahren
• EGW-Verfahren
• IFA-PASS-Verfahren
• integriertes Verfahren zur Aufwandsschätzung

Als Beispiel für ein Schätzungsverfahren soll nun das COCOMO-Verfahren kurz dargestellt werden, da eine tiefergehende Erläuterung dieses Themenbereiches den Rahmen dieser Arbeit sprengen würde.
Beim COCOMO-Verfahren handelt es sich um eine bereits recht alte Methode der Aufwandsschätzung (1981), mit deren Hilfe die Systemgröße in KDSI (Kilo lines of Delivered Source Instructions) geschätzt wird^[105]. "Aus der geschätzten Systemgröße in KSDI wird mittels mathematischer Formeln die Projektgröße in Personenmonaten bestimmt^[106]." Aus diesen Personenmonaten kann dann, unter anderem Mithilfe der Lohnkostensätze, der zu erwartende Projektaufwand geschätzt werden. Seit einiger Zeit gibt es eine sehr komplexe erweiterte Version (COCOMO II), die jedoch wenig praktikabel ist und daher in der Praxis selten angewandt wird^[107].
Abschließend bleibt noch zu erwähnen, dass die Aufwandsschätzung - vor allem wenn der Kunde dies wünscht oder bei internen Projekten - durchaus auch übersprungen werden kann^[108]. Kriterien für das Überspringen einer Aufwandsschätzung können zum Beispiel sein^[109]:

• es handelt sich um ein internes Projekt
• die Komplexität ist gering
• das Projekt wird von einer einzelnen Person durchgeführt
• der Funktionsumfang ist gering

Sollte nichts davon zutreffen, ist üblicherweise eine Aufwandsschätzung, wie zum Beispiel oben beschrieben, durchzuführen.

3.2 Risikomanagement

Zunächst soll der Begriff des Risikos für die folgende Beschreibung des Risikomanagement für IT-Projekte definiert werden. In der Literatur lassen sich unterschiedliche Definitionen finden, aus denen der Kernbegriff des Risikos abgeleitet werden soll.
Allgemeine Begriffsbeschreibungen sehen ein Risiko als „gewichtetes Muster möglicher Ereignisse und die damit verbundenen Folgen.“ ^[110].
Balzert beschreibt Risiko als ein potenzielles Problem, wobei ein Problem ein eingetretenes Risiko darstellt^[111].
Schnorrenberg definiert Risiko als „ein Ereignis, von dem nicht bekannt ist, ob es eintreten und/oder in welcher Höhe es einen Schaden verursachen wird“^[112].
Ahrendts, Marton gehen in ihrer Definition davon aus, dass es zwei wesentliche Charakteristika des Begriffs Risiko gibt, die in jeder Definition vorzufinden sind: die Unsicherheit und der Schaden. Anhand dessen definieren sie Risiko als „die Möglichkeit des Eintritts eines Schadens“^[113] bzw. als die „Möglichkeit Verlust zu erleiden“^[114].
Projektrisiken werden als „einmalige, im Hinblick auf die Projektziele ergebnisorientierte Risiken“^[115] definiert. Damit unterscheiden sie sich von operativen Risiken, die als „[..] häufig wiederkehrende, am Geschäftsprozeß [sich] orientierte, funktionale Risiken, [..]“ definiert werden^[116].
Der Gesetzgeber hat im Aktiengesetz, aufgrund der auch im Geschäftleben vorkommenden Risiken, die zur Insolvenzen führen können, im §91 Absatz 2 folgenden Satz aufgenommen "Der Vorstand hat geeignete Maßnahmen zu treffen, insbesondere ein Überwachungssystem einzurichten, damit den Fortbestand der Gesellschaft gefährdende Entwicklungen früh erkannt werden" ^[117]. Auch das Handelsgesetzbuch wurde entsprechend ergänzt: "Ferner ist im Lagebericht die voraussichtliche Entwicklung mit ihren wesentlichen Chancen und Risiken zu beurteilen und zu erläutern; zugrunde liegende Annahmen sind anzugeben" ^[118] und "Ferner ist im Konzernlagebericht die voraussichtliche Entwicklung mit ihren wesentlichen Chancen und Risiken zu beurteilen und zu erläutern; zugrunde liegende Annahmen sind anzugeben" ^[119]
Da ein Projekt im Unternehmen durchgeführt wird und dieses ggf. den Fortbestand der Gesellschaft gefährden könnte, ist auch im Projektmanagement ein Überwachungssystem für die dort auftauchenden Risiken zu etablieren und installieren, das so genannte Risikomanagement.
In der Literatur werden zwei Arten von Risikomanagement definiert: reaktives und proaktives Risikomanagement. Beim reaktiven Risikomanagement werden für aufgetretene Probleme Lösungen gesucht. Das proaktive Risikomanagement befasst sich mit möglichen Problemen bevor sie auftauchen und versucht Lösungen im Vorfeld zu finden^[120].
Ahrendts, Marton definieren das reaktive Risikomanagement als den geplanten „[..] Umgang mit Risiken in einem Projekt“^[121].
DeMarco definiert Risikomanagement als systematische Vorgehensweise, die Korrekturmaßnamen definiert bevor Probleme auftauchen^[122]. Laut der vorangegangenen Definition bezieht er sich mit dieser Definition auf das proaktive Risikomanagement.
Im weiteren Verlauf wird der Begriff des Risikomanagements auf das proaktive Risikomanagement bezogen.
Risikomanagement muss Risiken systematisch sichtbar machen und diese beurteilen^[123], um „deren Auswirkungen, die erst im späteren Projektverlauf auftreten, frühzeitig zu erkennen und geeignete und wirksame Projektsteuerungsmaßnahmen ergreifen zu können“^[124].
In Bruno werden drei verschiedene Projektrisiken dargestellt, die für das Risikomanagement von Bedeutung sind: Entwicklungsrisiken, Managementrisiken und soziale Risiken^[125]. Diese Projektrisiken werden wiederum in verschiedene Kategorien unterteilt.
Im Folgenden wird der Risikomanagementprozess dargestellt, der sich aus der Risikoidentifizierung, der Risikoanalyse, Risikopriorisierung, Risikosteuerung und der Risikoüberwachung zusammensetzt.

3.2.1 Risikoidentifizierung

Risiken und die daraus evtl. entstehenden Problemen können nur überwacht bzw. bekämpft werden, wenn sie im Vorfeld erkannt werden. Daher ist die Risikoidentifizierung ein entscheidender Faktor im Risikomanagement.
Für die Risikoidentifizierung können bereits erstellte Risikosammlungen, Checklisten und Erfahrungen von Mitarbeiten, die ähnliche IT-Projekte durchgeführt haben, herangezogen werden, sowie die Analyse vorliegender Projektdokumente^[126]. Mögliche Risikobereiche können sein^[127]:

• Leistungsrisiken: entstehen größtenteils durch Projektspezifikationen, die nicht detailliert genug gewesen sind. Z.B. durch nicht aufgenommene Leistungen oder unklare Spezifikationen. Zudem gehören auch technische Risiken zu den Leistungsrisiken.
• Terminrisiken: entstehen meist durch eingetretene Probleme im Projektgeschäft oder durch falsche Schätzung des Projektumfangs.
• Kostenrisiken: zu dieser Risikogruppe gehört der Ausfall der Zahlung durch den Projektauftraggeber, sowie die durch die verschiedensten Ursachen erhöhten Kosten.
• Ressourcenrisiken: hierzu gehören die Ausfallrisiken von Ressourcen sowie die nicht rechtzeitig oder mangelhafte Lieferung von Leistungen von Projektmitarbeitern.
• Projektmanagementrisiken: in diesem Bereich muss das Projektmanagement in die Risikobetrachtung mit einbezogen werden. Darunter fällt die Überprüfung der Fähigkeiten und Qualifizierung der/des Projektleiter/s. Zudem werden Risiken, die sich aus dem Projektteam ergeben können, betrachtet.
• Qualitätsrisiken: können den gesamten Projekterfolg durch nicht verwirklichte Projektziele gefährden.
• Konfigurationsrisiken: die im Hinblick auf abhängige Systeme und/oder Schnittstellen mit anderen Systemen verbundenen Risiken.

Die dargestellten Risikobereiche sind nicht vollständig, sondern zur Veranschaulichung möglicher Bereiche dargestellt.

3.2.2 Risikoanalyse

Nachdem die Risiken, die im laufenden Projekt eintreten können identifiziert sind, werden sie detailliert beschrieben. Anhand der Risikoanalyse wird danach die Risikopriorisierung durchgeführt. Da diese eine Schätzung ist, ist sie umso genauer, desto besser die Risiken beschrieben werden. Jedes Risiko wird einem Verantwortlichen zugeordnet, der die Aufgaben hat, die möglichen Ursachen, Folgen und Wechselwirkungen des Risikos festzustellen. Dabei muss dieser sich mit den entsprechenden Experten, Fachgruppen und/oder Unternehmensbereichen auseinander setzten, um einen genauen Überblick über das Risiko zu bekommen. Ergebnis der Risikoanalyse ist eine kompakte Beschreibung des Risikos, der Ursachen und Konsequenzen, der Einteilung in die entsprechende Projektphase in der das Risiko auftauchen kann, vor- und/oder nachgelagerten Risiken^[128].

3.2.3 Risikopriorisierung

Nach der Risikoanalyse werden die Risiken anhand ihrer Eintrittswahrscheinlichkeit und der Höhe des erwarteten Schaden geschätzt. Anhand der ermittelten Werte lassen sich die Risiken erkennen, für welche Maßnahmen ergriffen werden müssen.
Bei der Risikobewertung stellt sich die Frage, wer die Risiken zu bewerten hat. Dabei ist zu beachten, dass die Bewertungen von Risiken meist anhand von Schätzungen erfolgen. Da Schätzungen sich daran kennzeichnen lassen, dass sie subjektiv und das Ergebnis nicht als sicher anzusehen ist, sollte bei der Risikoeinschätzung eine Gruppe aus Leuten gebildet werden, die Projekterfahrung aus ähnlichen Projekten mitbringen und Leuten, die aus den finanziellen und politischen Projektbereichen Erfahrungen mitbringen.
Zur Bewertung von Risiken kann folgende Checkliste zu Rate gezogen werden^[129]:

• Prüfung der Ergebnisse der Risikoanalyse: Erneutes Prüfen, ob die Risiken richtig bewertet und die Ursachen und Konsequenzen vollständig dokumentiert worden sind.
• Schätzung der Risikohöhe: „die Risikohöhe entspricht den Kosten der Konsequenzen eines Risikos“^[130]. Aufgrund dessen wird jedes Risiko und die Konsequenzen einzeln bewertet und erst dann aufsummiert. Ist das Risiko nicht in Geldbeträgen zu ermitteln, können auch immaterielle Wertungen angegeben werden. Zum Beispiel lassen sich Risiken auch in Verzögerungszeiten anhand von Tages- oder Wochenzahlen oder Verringerung des Funktionsumfangs erfassen. Zudem lässt sich die Risikohöhe auch relativ bewerten, in einem vorgegebenen Berech beispielsweise von gering bis hoch. Dabei ist ein Vergleich mit anderen Risiken möglich, was wiederum eine Möglichkeit der Bewertung eines Risikos bietet.
• Schätzung der Eintrittswahrscheinlichkeit: Die Ursachen und Bedingungen des Risikos bestimmen die Eintrittswahrscheinlichkeit. Da jedes Projekt individuell ist, ist hier die Erfahrung aus anderen Projekten von großem Nutzen. Eine größere Eintrittswahrscheinlichkeit lässt sich in vielen Fällen anhand der Anzahl der Vorgängerrisiken herleiten.

Mit der ermittelten Eintrittswahrscheinlichkeit und Schadenshöhe lässt sich der Gesamtschaden ermitteln. Anhand des Gesamtschadens und der definierten Auswirkungen des Risikos lässt sich eine Priorisierung der Risiken vornehmen.

3.2.4 Risikosteuerung

Im Schritt Risikosteuerung werden Maßnahmen und Strategien für die Risiken festgelegt. Dabei legen Ahrendts und Marton vier Risikostrategien zugrunde^[131]:

• Risikoakzeptanz: es werden keine Steuerungsmaßnahmen entwickelt. Wird für Risiken mit geringer Eintrittswahrscheinlichkeit und geringer Schadenshöhe eingesetzt.
• Risikoverlagerung: die Risiken werden auf eine andere Partei übertragen. Wird für Risiken eingesetzt, die zu einem hohen Schadenswert führen können, bei denen die Eintrittswahrscheinlichkeit jedoch relativ gering ist.
• Risikoverminderung: die Eintrittswahrscheinlichkeit und die Höhe des Schadens wird versucht zu reduzieren. Kann für Risiken verwendet werden, die nicht vermieden werden können, deren Schadensausmaß / Eintrittswahrscheinlichkeit jedoch nicht sehr groß sind.
• Risikovermeidung: es werden Maßnahmen ergriffen, die die Eintrittswahrscheinlichkeit praktisch auf Null senken sollen. Diese Maßnahmen sollten für Risiken definiert werden, die eine sehr hohe Eintrittswahrscheinlichkeit und Schadenshöhe haben.
  

Für die einzelnen Risiken ist nun eine Strategie festzulegen, um daraus ableitend Maßnahmen zu definieren. Dabei werden Aktivitäten innerhalb der Maßnahmen konkretisiert und diese Aktivitäten einzelnen Mitarbeiten zugeordnet.

3.2.5 Risikoüberwachung

Nach Abschluss der Maßnahmenfindung für die Risiken müssen diese einerseits überwacht und das Projekt gleichzeitig nach neuen Risiken überprüft werden. Ziel dabei ist es, das Eintreten von Risiken frühzeitig zu erkennen um die entwickelten Maßnahmen rechtzeitig anwenden zu können. Zusätzlich sollen Veränderungen der Risiken erkannt werden.
Jedem Risiko ist ein Verantwortlicher zuzuweisen. Dabei ist es sinnvoll einen Mitarbeiter im Projekt auszusuchen, der mit den jeweiligen Ursachen des Risikos vertraut ist. Dieser kann auch die Veränderungen der Risiken am schnellsten erkennen. Zusätzlich kann ein Risikomanager eingesetzt werden, der die Verantwortung der Überwachung aller Risiken übernimmt.
Als weitere Maßnahmen der Risikoüberwachung können in die regelmäßigen Projektmeetings der aktuelle Status der Risiken aufgenommen und diskutiert werden. Andernfalls sind separate Risikomanagementmeetings anzusetzen, in denen die Risikoverantwortlichen über den aktuellen Status berichten können.

3.3 Projektkontrolle

Ohne eine regelmäßige Erfassung des Projektfortschritts und des Projektstatus können auftretende Probleme oder Abweichungen vom Projektplan, insbesondere in zeitlicher Hinsicht und im Hinblick auf die Kosten nicht rechtzeitig erkannt und an die Projektlenker kommuniziert werden. Damit z.B. der Zeitplan oder die Kosten erst gar nicht überschritten werden, bedarf es eines wirksamen Projektcontrollings. Betrachtungsobjekte sind neben dem Terminplan und dem Budget auch die Qualität der Leistungserbringung^[132].
Kontrollen finden nicht nur während des Projektverlaufes statt, sondern auch nach Abschluss des Projektes. Die Projektabschlusskontrollen dienen der Bewertung des Projektverlaufes und des Projektergebnisses. Weitere Kontrollen finden nach der Produktivsetzung statt, um das Projektergebnis während der Nutzung im Hinblick auf Nutzbarkeit, Qualität und Wirtschaftlichkeit zu beurteilen^[133].

3.4 Projektcontrolling

IT-Projektcontrolling hat die zentrale Funktion, das Projektmanagement bei der Zielerreichung zu unterstützen und die frühzeitige Beeinflussung des Projektes zum Ziel. Termine, Kosten und Ressourcenverbräuche werden kontinuierlich verfolgt, was die frühzeitige Erkennung von Planabweichungen, Schwachstellen und Fehlentscheidungen ermöglicht. Korrekturmaßnahmen können frühzeitig eingeleitet werden. Die Durchführung dieser Maßnahmen wird ebenfalls überwacht. Sind die Abweichungen nicht mehr korrigierbar, so sind evtl. Plananpassungen vorzunehmen^[134].

Dabei sind diese Aufgaben von der Projektleitung wahrzunehmen. Erst bei komplexeren Projekten ist ein institutionalisiertes Projekt-Controlling notwendig. In diesem Fall wird explizit ein Projekt-Controller eingesetzt, der jedoch meist nicht verantwortlich für die Auswahl und Einleitung der Gegenmaßnahmen ist, sondern das Management lediglich über Fehlentwicklungen informiert und Entscheidungsalternativen aufzeigt. Durch die Mitarbeit eines IT-Controllers im IT-Projektteam kann die Projektleitung von einem Spezialisten entlastet und unterstützt werden^[136]. Die Abbildung 9 zeigt exemplarisch Probleme mit typischen Gegenmaßnahmen und den daraus resultierenden Konsequenzen auf:

Um der Projektleitung die Entscheidungsfindung zu erleichtern, dürfen die als Grundlage zur Steuerung dienenden Informationen den Entscheider nicht überfordern. Um sich möglichst schnell einen Überblick verschaffen zu können, werden hochverdichtete Kennzahlen erstellt. Mit ihnen lassen sich komplexe Sachverhalte einfach darstellen. Dabei müssen die Kennzahlen mit einem angemessenen Aufwand erhoben werden können und nützliche Informationen liefern. Zudem ist zu beachten, dass die Kennzahlen auf Grund der kompakten Darstellung der Realität einer korrekten Interpretation bedürfen. Bei der Auswahl der Kennzahlen ist zunächst festzustellen, welche Anforderungen das Kennzahlensystem an den Informationsbedarf erfüllen muss und welche Informationen in welchem Detaillierungsgrad zur Steuerung nötig sind^[138].

In Bezug auf IT-Projekte können die folgenden Kennzahlen sinnvoll sein^[139]:

• Fertigstellungsgrad
• Durchschnittliche Anzahl an Projektbeteiligten
• Projektkosten pro Mitarbeiter
• Projektkosten pro Anwender

Die Kennzahlen sollten regelmäßig überprüft und angepasst werden. Die Kennzahlen sind zu verwenden, um sie mit Marktkennzahlen oder Kennzahlen der Wettbewerber oder anderweitig bereits realisierten ähnlichen Projekten zu vergleichen. Damit lassen sich nicht nur Soll-Ist-Abweichungen feststellen, sondern auch die Qualität des Projektes und der erbrachten Leistungen.

3.5 Projektsteuerung

Die Projektplanung bildet die Basis für ein Projekt. Die dort getroffenen Entscheidungen müssen dann anhand von Maßnahmen umgesetzt werden. Die Projektsteuerung umfasst diese Maßnahmen. Die Projektplanung und die Projektkontrolle bilden die Basis für die Projektsteuerung, wobei die Projektsteuerung ein permanenter Prozess ist, der während der gesamten Projektlaufzeit läuft. Dabei unterstützt die Projektsteuerung die Festlegung von Erfolgskriterien und Kenngrößen die Abweichungen erkennen lassen und verfolgt und interpretiert den Projektfortschritt anhand der Projektpläne. Die Projektsteuerung kann somit Unsicherheiten im Projektverlauf reduzieren^[140]. Die zu ergreifenden Maßnahmen sind vom jeweiligen Projekt und der Art der Abweichung abhängig. Sie können in folgende projektübergreifende Maßnahmengruppen eingeteilt werden^[141]:

• Maßnahmen zur Überprüfung der von der Projektkontrolle festgestellten Abweichungen
• Maßnahmen zum Erkennen der Ursachen für Abweichungen
• Maßnahmen zum Beeinflussen der Projektabwicklung, die eine Verbesserung der Istwerte bewirken
• Maßnahmen zum Beeinflussen der Projektabwicklung, die eine Verbesserung der Planwerte bewirken
• Maßnahmen, die das Koordinieren zwischen Auftraggeber und Projektgruppe sowie zwischen den verschiedenen Arbeitsgruppen im Projekt bewirken

Zudem können Projektbeschleunigungsmaßnahmen, Maßnahmen zur Qualitätssteigerung, Leistungssteigerung und Kostensenkung durch die Projektsteuerung festgelegt werden^[142].

3.6 Qualitätssicherung

Die Qualitätssicherung dient der Absicherung des Projektes. Sie wird jedoch meist nicht zu den Primärzielen wie die Einhaltung der Zeit und des Budgets gezählt, obwohl sie die anderen Projektziele unterstützen und sogar fördern kann^[143]. Gerade in kleineren Projekten nimmt das Qualitätsmanagement nur einen geringen Platz ein. Es gibt jedoch bestimmte Aktivitäten, die in jedem Fall durchgeführt werden sollten.

Qualitätssicherung teilt sich dabei in zwei Bereiche auf. Zum Einen ist dies das konstruktive Qualitätsmanagement, das gewährleisten soll, dass nach vorgegebenen dokumentierten Richtlinien vorgegangen wird. Im Beispiel einer Softwareentwicklung können dies Programmierrichtlinien sein. Zum Anderen ist dies die analytische Qualitätssicherung, die das Testen der Projektergebnisse umfasst.^[144].

Zur Qualitätssicherung sind entsprechende Maßnahmen durchzuführen, die sowohl intern z.B. in der Funktion als QS-Beauftragter, als auch von unabhängigen externen sachverständigen Dritten wahrgenommen werden können. Eine sehr wirksame, aber auch aufwendige Maßnahme sind Reviews. Im Rahmen von Reviews wird ein Ergebnis durch einen möglichst unabhängigen Dritten bewertet. Regelmäßige und insbesondere zeitnahe Reviews ermöglichen die frühzeitige Erkennung von Planabweichungen, Schwachstellen und Fehlentscheidungen. Sie sind auf Grund des hohen Aufwandes insbesondere bei sehr komplexen und kritischen Teilprojekten sinnvoll, da gerade dann das Entdecken von Fehlern größere Probleme verhindern kann und sich der Aufwand besonders lohnt. Sind nur wenige Mitarbeiter im Projekt involviert und die fachliche und technische Komplexität relativ gering, kann im Hinblick auf den hohen Aufwand auf Reviews auch tendenziell verzichtet werden.

Die Ergebnisse der Qualitätssicherung werden in Form von QS-Berichten kommuniziert. Damit soll den Projektverantwortlichen eine unabhängige Sicht über den Projektstand geliefert werden^[145].

Die Berichtserstellung durch die Qualitätssicherungsbeauftragten stellt nur einen Teilbereich des Berichtswesens dar. So muss der QS-Beauftragte nicht nur Berichte erstellen, er verschafft sich auch anhand von Berichten und Dokumentationen der jeweiligen Teilprojekte einen Überblick.

Das gesamte Berichts- und Dokumentationswesen hat sicherzustellen, dass einzelne Probleme derart kommuniziert werden, dass sie frühzeitig erkannt und bearbeitet werden und sich in Verbindung mit Problemen aus anderen Teilprojekten nicht zu einem projektgefährdenden Risiko kumulieren können. Risiken ergeben sich insbesondere aus einem unzureichenden Informationsfluss zwischen Projektbeteiligten und den zuständigen Entscheidungsträgern. Die Informationswege müssen die zeitgerechte Dokumentation und Kommunikation der Projektergebnisse und Entscheidungen sicherstellen. Eine Weiterleitung sollte nach definierten Eskalationsstufen über die zuständigen Hierarchieebenen bis zu der Unternehmensleitung erfolgen. Trotz der einzuhaltenden förmlichen Berichtsstrukturen müssen diese bei Notwendigkeit überwunden und Kommunikationswege und –zeiten verkürzt werden^[146].

Berichte und Dokumentationen richten sich an die unterschiedlichsten Empfänger mit sehr unterschiedlichen Informationsbedürfnissen. Bei der Erstellung sollte dies beachtet werden. Generell gilt, dass so viel wie nötig und so wenig wie möglich zu dokumentieren ist. So verschwenden lange, unübersichtliche Dokumentationen insbesondere zeitliche Ressourcen sowohl des Erstellers als auch die des Empfängers.

3.6.1 Projektdokumentation

Jedes Projekt sollte in eine aktuelle und vollständige Dokumentation aufgenommen werden. Dies wird vielfach als zu aufwändig und unnötig angesehen, was jedoch ein Irrglaube ist. Eine Projektdokumentation erfüllt viele Funktionen. So stellt sie insbesondere eine wertvolle Informationsbasis für Projektmitglieder und spätere Anwender dar. Entsprechend der DIN 69901 ist sie eine „Zusammenstellung ausgewählter, entscheidender Daten über die Konfiguration, die Organisation, den Mitteleinsatz, die Lösungswege, den Ablauf und die erreichten Ziele des Projektes“ ^[147]. Hier zeigt sich bereits, dass die Dokumentation sehr vielfältig ist:

Die Anforderungen an ein Projektziel, also z.B. an die Funktionen, die eine eigenerstellte oder fremderworbene Software gestellt werden, sind in Lasten-/Pflichtenheften zu definieren und in Grob- und Feinkonzepten zu dokumentieren. Die Codierung wird in technischen Konzepten und Implementierungskommentaren dokumentiert.

Die Anwendbarkeit wird durch die Erstellung von Anwenderhandbücher für die Benutzer und der Dokumentation der Systemeinrichtung für die Administration sichergestellt. Die Systemdokumentation stellt sicher, dass das Projekt unabhängig von den beteiligten Personen für das Unternehmen transparent wird und damit die Unabhängigkeit des Unternehmens von einzelnen Personen gewährleistet wird.

Die Fehlerfreiheit wird durch Test- und Abnahmeprozeduren sichergestellt, die in Testkonzepten und Abnahmeerklärungen dokumentiert werden. Die Freigabeerklärungen der Teilprojekte sollten von den Fachabteilungen erfolgen, da diese das KnowHow mitbringen und letztlich das Ergebnis nutzen müssen^[148].

Fehler aus vergangenen Projekten lassen sich vermeiden, wenn die Erfahrungen dokumentiert wurden. Für die Nachkalkulation eines Projektes oder für die Kalkulation zukünftiger Projekte müssen ebenfalls Dokumentationen erstellt werden. Projektbenchmarking, also der Vergleich von Projekten, setzt ebenfalls eine Dokumentation voraus^[149].

Betrifft ein Projekt das IT-gestützte Buchführungssystem, also z.B. die Einführung einer neuen Buchführungssoftware, dann bestehen auch besondere rechtliche Anforderungen an die Dokumentation. So muss die Buchführung gemäß § 238 HGB so beschaffen sein, dass sich ein sachverständiger Dritter innerhalb angemessener Zeit einen Überblick über die Geschäftsvorfälle und die Lage des Unternehmens verschaffen kann. Die Buchführung hat zudem nach den Grundsätzen ordnungsmäßiger Buchführung zu erfolgen. Hieraus ergibt sich unter anderem der Grundsatz der Nachvollziehbarkeit. Demnach muss beim Einsatz IT-gestützter Rechnungslegungsverfahren auch das Buchführungsverfahren nachvollziehbar sein. Voraussetzung für die Nachvollziehbarkeit ist eine entsprechende Dokumentation, die dem sachverständigen Dritten die Beurteilung der komplexen Verfahren ermöglicht. Bei der Einführung von Individualsoftware ist dies z.B. die technische Systemdokumentation, im Falle von Standardsoftware die Programmbeschreibung. In beiden Fällen kommt die Dokumentation über das Customizing, also der im Projekt durchgeführten Anpassungen an die Unternehmensanforderungen^[150].

Die folgende Übersicht^[151] stellt einen Auszug aus in einem Projekt zu erstellenden Dokumentationen dar^[152]:

• Projektplan inkl. Termin- und Meilensteinplänen
• Projektkalkulation
• Machbarkeitsstudie
• Projektantrag
• Projektauftrag
• Projekthandbuch
• Organisatorische Dokumentationen (Organigramme, Aufgaben- und Verantwortungsverteilungspläne, Kontaktdatenlisten)
• Fachkonzepte / Feinkonzepte
• Pflichtenheft
• Entwicklungsauftrag
• technisches Konzept
• Softwarearchitektur
• Testkonzept
• Abnahmeerklärungen
• Berechtigungskonzept
• Migrationskonzept
• Schulungskonzept
• Systemdokumentation (technische Dokumentation, Dokumentation der Systemeinrichtung, Benutzerhandbuch)
• Projektstatusberichte
• Offene-Punkte-Listen

Nachfolgend werden einige Dokumente kurz erläutert^[153]:

Das Projekthandbuch beinhaltet alle Rahmenbedingungen und stellt damit eine Informationsgrundlage für alle Projektbeteiligte dar. Es ist aus diesem Grunde ständig aktuell zu halten und um neue Informationen zu erweitern. Es kann eine Sammlung der hier aufgezählten Dokumente darstellen. Ein Projekthandbuch kann auch allgemeinen Charakter haben und generelle Vorgaben für Projekte geben. Ein allgemeingültiges Projekthandbuch kann Angaben zu der von der Unternehmensleitung bevorzugten Projektorganisation, dem Führungsstil, Dokumentationen und deren Struktur und sonstigen Projektgrundsätzen enthalten.

Der Projektplan ist meist das erste zu erstellende Dokument. Bei großen Projekten sollte er im Rahmen einer Präsentation allen interessierten Personen vorgestellt werden, insbesondere um eine hohe Akzeptanz für das Projekt zu erzielen. Die besondere Bedeutung sollte durch Anwesenheit eines Mitarbeiters der Unternehmensleitung herausgestellt werden. Der Projektplan enthält alle notwendigen Plandaten inkl. dem Terminplan und den Meilensteinen und beschreibt das Ziel und den Ablauf des Projektes. Er enthält viele Planwerte, die möglichst konkret kalkuliert werden sollten. Die Erstellung sollte daher von erfahrenen Personen vorgenommen werden und die Erkenntnisse aus vergangenen Projekten einfließen. Bei komplexen Projekten kann auch eine Parallelschätzung vorgenommen werden. Die Planwerte werden mit fortschreitendem Projekt konkretisiert und angepasst.

Mit dem Pflichtenheft werden die Anforderungen an das Projektergebnis definiert. Es stellt einen Kriterienkatalog dar, den das System erfüllen muss. Dabei können KO-Kriterien und Gewichtungen einzelner Kriterien festgelegt werden. Im Falle eines externen Auftragnehmers verpflichtet sich dieser mit seiner Angebotsabgabe zur Erfüllung der aus dem Pflichtenheft vereinbarten Funktionen.

Das technische Konzept und die Systemdokumentation richten sich primär an die Entwickler, Betreuer und Administratoren des Systems. Das technische Konzept beinhaltet dabei eher die benötigten Informationen vor der Anwendbarkeit, während die Systemdokumentation eine Beschreibung des fertigen Projektergebnisses enthält. Beide können beispielsweise Informationen zur Installation, dem benötigten Speicherplatz, den Systemvoraussetzungen, zur Verzeichnisstruktur, zu den einzelnen benötigten oder installierten Dateien, zu Erweiterungsmöglichkeiten, den Schnittstellen und zum Aufsetzen auf der Datenbank enthalten. Daneben sollten Informationen zum Betrieb des Systems und den notwendigen Arbeiten im Regelbetrieb, wie z.B. der Überwachung der Komponenten oder Log-Dateien, möglichen Fehlern und den einzuleitenden Maßnahmen zu finden sein. Das Benutzerhandbuch ermöglicht dem künftigen Anwender die sachgerechte Nutzung. Die Funktionalitäten sollten ausführlich und verständlich beschrieben sein, unterlegt mit Beispielen. Auch für den Anwender sollten die möglichen Probleme mit für ihn umsetzbaren Lösungsmöglichkeiten dargestellt sein. Ein nicht ausreichend dokumentiertes IT-System kann bei der späteren Nutzung zu Problemen führen und auch gegen rechtliche Anforderungen verstoßen. Insbesondere die Grundsätze der Nachvollziehbarkeit und Prüfbarkeit sind nur bei Vorhandensein ausreichender Dokumentationen erfüllt.

An die gleichen Adressaten richtet sich die Dokumentation der Software- bzw. Systemarchitektur, die dem Verständnis und der Nachvollziehbarkeit dient. Es sollten die wesentlichen Funktionen, der Aufbau und die Schnittstellen des Systems dargestellt werden. Ebenso kann eine Aussage über die Programmiersprache und die Entwicklungsumgebung oder die Systemvoraussetzungen getroffen werden.

Das Testkonzept beschreibt die durchzuführenden Tests, um alle vereinbarten Funktionalitäten abzudecken und die Fehlerfreiheit des Projektergebnisses bestätigen zu können. Dazu gehören auch die Testprotokolle, in denen die Durchführung der Tests bestätigt und das Ergebnis dokumentiert wird. Die hierbei relevanten Informationen sind die Art des Tests, der Testbereich, die Testbedingungen, das erwartete und das tatsächliche Ergebnis und eine Aussage, ob der Test als erfolgreich gewertet werden kann. Die Dokumentation sollte möglichst detailliert sein, um bei Abweichungen Verbesserungsmaßnahmen auf Basis des Testergebnisses einleiten zu können.

Abnahmeerklärungen geben ein Projektergebnis offiziell frei. Gewöhnlich werden Abnahmeerklärungen nur bei Projekten mit externen Auftraggebern bzw. Auftragnehmern erstellt. Neben der Abnahme des Gesamtergebnisses können auch, falls vorgesehen, Teilergebnisse abgenommen werden. Dabei sollte die Abnahmeerklärung den eindeutigen Namen des Projektes, das Abnahmedatum und evtl. Einschränkungen oder Gründe im Falle eines nicht abgenommenen Projektes beinhalten.

In den genannten Konzepten werden Sachverhalte möglichst genau und nachvollziehbar erläutert. Dem Anwender soll ermöglicht werden, anhand der Konzepte Lösungen selbst anzuwenden. So soll z.B. ein Migrationskonzept darstellen, wie die Daten aus dem Alt-System in ein neu erstelltes System übertragen werden. Das Berechtigungskonzept soll alle Rahmenbedingungen für die Vergabe von Rollen und Berechtigungen an die User beschreiben.

Alle aufgezählten Dokumente sollten mindestens den Namen des Projektes und den verantwortlichen Autor enthalten. Damit der Speicherort einer ausgedruckten Datei ohne große Mühe wiedergefunden werden kann sollte ebenfalls der Pfad- und Dateiname mit aufgenommen werden. Finden Änderungen am Dokument statt, so sollte eine Versionierung erfolgen mit Angabe des Datums, des Bearbeiters und den vorgenommenen Änderungen. Nicht freigegebene Dateien sollten als solche kenntlich gemacht werden z.B. mit einer Kennzeichnung als Entwurf. Zudem sollte ganz generell Wert auf die folgenden Qualitätskriterien gelegt werden^[154]:

• Vollständigkeit
• Einheitlichkeit, Strukturiertheit und Übersichtlichkeit
• Benutzbarkeit und Anschaulichkeit
• Änderbarkeit und Anpassungsfähigkeit
• Widerspruchsfreiheit
• Aktualität
• Wirtschaftlichkeit der Erstellung

Die Anfertigung der Dokumentationen kann zu unterschiedlichen Zeitpunkten erfolgen. Grundsätzlich wird zwischen Vorwärts-, Simultan- und nachträglicher Dokumentation unterschieden, wobei die Simultandokumentation, also das Festhalten der Ergebnisse während ihrer Durchführung, die ideale Lösung darstellt. Durch die zeitnahe Erstellung ist sie aktueller, beinhaltet daher weniger Fehler und benötigt weniger Zeit. Die Vorwärtsdokumentation hingegen ist kaum praktikabel, da das Projekt nahezu immer vom Plan abweicht^[155].

3.6.2 Laufende Berichterstattung

Mit einer laufenden Berichterstattung werden die Ergebnisse, die Einhaltung des Budgets und die Termineinhaltung überprüft.

Die laufende Berichterstattung erfolgt meist in Form von Protokollen, Status- und Zwischenberichten. Protokolle werden dabei eher stichpunktartig erstellt während Berichte meist ausführlicher formuliert werden.

Die Dokumentation des Projektfortschritts erfolgt in Form von Statusberichten. Sie sollten zu festgelegten Zeitpunkten regelmäßig oder bei besonderen Anlässen erstellt werden und den Projektstatus unverfälscht darstellen. Probleme müssen offen kommuniziert werden, um Korrekturmaßnahmen frühzeitig und basierend auf realistischen Informationen treffen zu können.

Empfänger von Zwischenberichten sind insbesondere Projektlenker, die auf Basis der aus den Berichten gewonnenen Informationen Entscheidungen treffen. Dies bedeutet, dass der Qualität ein hoher Stellenwert beizumessen ist. Nur ausreichend versierte Mitarbeiter sollten diese Aufgabe wahrnehmen. Es gilt die richtigen Informationen zum richtigen Zeitpunkt in hinreichender Menge zur Verfügung zu stellen. Zu den relevanten Informationen zählen insbesondere der Berichtszeitraum, die Beschreibung der aktuellen Situation mit den evtl. zu lösenden Problemen und Entscheidungsalternativen. Häufig werden alternative Lösungen nicht dokumentiert, obwohl die aufgezeigten Alternativen mit Hilfe detaillierter Informationen erst eine Entscheidung ermöglichen. Hierzu zählen insbesondere Informationen zu den Kosten, der benötigten Zeit und dem sonstigen Ressourcenbedarf wie z.B. Personal. Evtl. kann ein Entscheidungsvorschlag unterbreitet werden, der jedoch einer entsprechenden Begründung bedarf und ergänzt werden sollte mit zusätzlichen Unterlagen wie Gutachten etc.^[156].

Protokolle dienen dazu einen Verlauf oder Sachverhalt kurz und knapp zu dokumentieren. Die häufigste Form sind Gesprächs- und Besprechungsprotokolle. Sie sollten Informationen über den Anlass, den Ort und die Zeit der Besprechung und eine Liste der Teilnehmer beinhalten ^[157]. In der Regel sollten in die Protokolle nur die wichtigsten Erkenntnisse und Meinungsäußerungen aufgenommen werden.

4 Anwendungsbeispiel

Das Unternehmen Arning & Bachmann GmbH wurde von dem Konzern Weisenhaus AG übernommen. Beide Unternehmen nutzen eigenständige SAP-Systeme als Rechnungslegungssysteme. Nun strebt der Konzern Weisenhaus AG eine Harmonisierung des internen und externen Berichtswesens an. Das Projekt ist maßgeblich entstanden aus hieraus resultierenden externen Anforderungen an die Konzern-Berichterstattung hinsichtlich Integration und Nachprüfbarkeit. Im Rahmen eines Abstimmungsprozesses innerhalb des Bereiches Finanzen wurden die inhaltlichen Eckpunkte sowie die systemtechnischen Erfordernisse festgelegt.

4.1 Projektziel

Das IT-gestützte Rechnungswesen der beiden Gesellschaften soll harmonisiert werden. Inhaltlichen Notwendigkeiten wie IAS-Fähigkeit und Segmentberichterstattung sollte Rechnung getragen werden. Zwischen dem internen und externen Rechnungswesen sollen keine Abweichungen im Berichtswesen auftreten. Zusätzlich soll eine Segmentberichterstattung eingeführt werden.

Der Konzern formulierte die folgenden Ziele:

• Harmonisierung des internen und externen Berichtswesens
  • Gesamtkonzernabschluss
  • Übereinstimmung der Deckungsbeitragsrechnung und der GuV
• Einführung einer Segmentberichterstattung
  • Berichtswesen nach Regionen und Segmenten (Geschäftsfeldern)
  • Konsolidierung innerhalb eines Segmentes

Zur Erreichung der Hauptziele wurden Teilziele definiert, um den Aufwand für das neue Hauptbuch für den Konzern so gering wie möglich zu halten:

• Kontenplanumstellung auf den Konzernkontenplan der Weisenhaus AG
• Kostenrechnungskreiszusammenführung zu einem Kostenrechnungskreis
• Einführung des neuen Hauptbuches
• Einführung der Profit-Center-Rechnung

4.2 Projektorganisation

Neben den beiden Unternehmen wurde ein externes Beratungsunternehmen beauftragt, um die Unternehmen mit Hilfe von Spezialisten zu unterstützen. Insbesondere die technischen Umsetzungen im SAP-System der Arning & Bachmann GmbH sollten von den Beratern durchgeführt werden.

Die Kompetenz des Beratungsunternehmens konnte anhand von Referenzprojekten nachgewiesen werden. Zudem gab es bereits positive Erfahrungen aus der Zusammenarbeit in früheren Projekten. Dennoch wurden Vergleichsangebote zur Absicherung eingeholt.

Das Gesamtprojekt wurde in Teilprojekte unterteilt:

• Teilprojekt neues Hauptbuch
• Teilprojekt Konsolidierung
• Teilprojekt Kontenplanumstellung
• Teilprojekt Zusammenlegung Kostenrechnungskreis

Es wurde eine Liste erstellt mit allen Projektbeteiligten, ihren Kontaktdaten und den Projekt-Rollen. Die Aufgaben und die Verantwortungen wurden unter den Beteiligten aufgeteilt. Hierbei wurde unterteilt in die Funktionen

• Verantwortung
• Unterstützung
• Coaching

Daneben wurde ein Organigramm erstellt.

Ein Feinkonzept enthielt detaillierte Beschreibungen der einzelnen Projekte mit Terminplan, Anforderungen und Prozessen.

Es wurde ein Projekt-Zeitplan aufgestellt, der die Teilprojekte mit den jeweiligen Start- und Endterminen und Meilensteine enthielt. Dabei wurde festgelegt, dass bestimmte Teilprojekte hintereinander abgeschlossen werden, da die Beendigung des einen Teilprojekts Voraussetzung für die Umsetzung des anderen Teilprojektes war. So erfordert die Zusammenlegung der Kostenrechnungskreise zunächst die Umstellung des Kontenplans im Rechnungslegungssystem. Einzelne vorbereitende Projektaktivitäten konnten jedoch parallel erfolgen.

Es wurden Kick-Off Veranstaltungen und regelmäßige Workshops abgehalten, um den aktuellen Projektstatus festzustellen und Fragestellungen zu diskutieren. Hierzu wurden jeweils kurze Präsentationen zur Themeneröffnung und im Nachgang Besprechungsprotokolle erstellt. In den Besprechungsprotokollen wurden Lösungsalternativen mit ihren jeweiligen Vor- und Nachteilen aufgezeigt. Daneben wurde der Zeitplan abgefragt und die Einhaltung kontrolliert.

Es wurde eine Testumgebung in Form einer Kopie der Produktivumgebung geschaffen, um die Teilprojekte unter echten Bedingungen testen zu können.

4.3 Projektdokumentation

Da die Kontenplanumstellung die gleichen rechtlichen Anforderungen zu erfüllen hat wie eine Jahresabschlussumstellung, mussten revisionssichere Dokumentationen erstellt werden, sowohl in schriftlicher Form als auch digital in Form von Dateien und im System. Dies gilt insbesondere für die Grundsätze der Ordnungsmäßigkeit und Nachvollziehbarkeit.

Im Rahmen des Projektes wurden die folgenden Dokumentationen erstellt:

• Organisatorische Dokumentationen (Organigramme, Aufgaben- und Verantwortungsverteilungspläne, Kontaktdatenlisten)
• Projektplan inkl. Termin- und Meilensteinpläne
• Feinkonzepte
• Eröffnungs-Präsentationen zu den jeweiligen Workshops und Kick-Off-Veranstaltungen
• Besprechungsprotokolle
• Projektstatusberichte
• Offene-Punkte-Listen

4.4 Projektkontrolle und -Controlling

Durch die Beteiligung eines Projekt-Controllers wurden folgende Feststellungen getroffen:

• Das Projekt „Neues Hauptbuch“ erfordert eine Umstellung des Kontenplanes
• Die Umstellung sollte unterjährig erfolgen
• Mit den Wirtschaftsprüfern sollte frühzeitig abgestimmt werden, welche Dokumente vor der Umstellung zu erstellen sind
• Es dürfen keine offene Batch-Input-Mappen zum Zeitpunkt der Umstellung im SAP-System vorhanden sein
• Die Daten der Historie für das Rechnungswesen können z.B. mit Hilfe des SAP-Tools DART gespeichert werden
• Für die Segmentberichtserstattung wird eine Profit-Center Struktur benötigt

Zur Kontrolle des Projektes wurde die Wirtschaftsprüfungsgesellschaft eingebunden. Es wurde eine projektbegleitende Prüfung angestrebt. Dabei wurden folgende Feststellungen getroffen:

• Bei der produktiven Umsetzung muss eine Volldatenbanksicherung vor und nach Umsetzung durchgeführt werden. Diese Datenbanksicherungen müssen zur Erfüllung gesetzlicher Anforderungen 10 Jahre aufbewahrt werden.
• Die Dateien auf den Fileserver sollten zusätzlich für eine kurze Zeit auf externen Speichermedien gespeichert werden, um später bei Problemen in der Projektumsetzung evtl. Reviews durchführen zu können
• Bei der Umsetzung sind alle User zu sperren, die nicht an der produktiven Umsetzung beteiligt sind, damit keine unberechtigten Datenzugriffe erfolgen können und zu Inkonsistenzen im Datenbestand führen
• Zur Prüfung der richtigen Zuordnung der Daten auf den neuen Kontenplan müssen vor und nach der Umstellung Auswertungen erstellt werden. Es können nur Summen verglichen werden, weil sich die Kontenstruktur ändert. Es müssen Auswertungen über Summen-Salden-Listen, Bilanz, Anlagegitter und die Bilanz erstellt werden. Dabei handelt es sich um eine Stichtagsauswertung

Zur Kontrolle der fehlerfreien Umsetzung forderte die externe Revision die Erstellung der folgenden Unterlagen:

• Feinkonzept (Projektbeschreibung)
• Umsetzregeln des Fachbereiches
• Projektplan
• Testpläne
• Cut-over Plan der Umsetzung
• Umsetzregelwerk
• Liste der umgesetzten Tabellen
• Protokolle der Umsetzung

4.5 Projektverlauf

Um den ordnungsgemäßen Ablauf der Kontenplanumstellung und in dem Zuge das Überleiten der Daten vom alten auf den neuen Kontenplan nachweisen zu können, wurden Summen- und Saldenlisten vor und nach der Umstellung aus dem SAP-System generiert. Für das aus- und einlesen der Daten wurde ein spezielles Tool des Beratungsunternehmens eingesetzt, welches die Anzahl der aus den alten Konten ausgelesenen und in die umgestellten Konten des neuen Kontenplans eingespielten Sätzen protokollierte und als PDF-Datei auf das Netzlaufwerk der Arning & Bachmann GmbH automatisch ablegte. An Hand dieser Dateien konnte die Controlling-Abteilung und das Wirtschaftsprüfungsunternehmen im Nachgang die vollständige Übertragung aller Daten überprüfen. Hierbei wurde festgestellt, dass mehrfach bei der Verdichtung zweier alten Konten auf ein neues Konto keine Einzelposten übertragen wurden. Der Fehler wurde manuell von den Mitarbeitern der Finanzbuchhaltung korrigiert.

Das Projekt konnte auf Grund der guten Zusammenarbeit aller Beteiligten, der ausführlichen Vorbereitung und der ausreichenden Dokumentation erfolgreich abgeschlossen werden.

5 Schlussbetrachtung

Im Rahmen der Fallstudie wurde festgestellt, dass sich die Aufgaben von Projektmanagement und IT-Projektmanagement nicht maßgeblich voneinander unterscheiden. Im IT-Projektmanagement müssen die Beteiligten auf die Besonderheiten der IT-Projekte eingehen, deren Methoden und Vorgehensweisen kennen, um Projekte zeitgemäß, in der richtigen Qualität und innerhalb der geplanten Kosten abzuschließen. Dies ist keine grundsätzliche Neuerung gegenüber dem Management anderer Projekte. Der grundsätzliche Aufbau des Projektmanagements, die Planung, Steuerung und Kontrolle, ist derselbe.
Trotzdem scheiterten laut einer Studie aus dem Jahr 1999 ein Drittel aller Projekte und die Hälfte überzog den geplanten Zeitrahmen oder das Budget^[158].
In einer Studie aus 2006 scheiterten 19 % aller Projekte komplett, 46 % überzogen das Budget oder waren teuerer als geplant. Projekte die erfolgreich verlaufen sind machten 35 % aus^[159].
Anscheinend ist das erfolgreiche Abschließen von IT-Projekten nicht selbstverständlich und Bedarf weiterer Analysen und Hilfestellungen. In verschiedenen Studien ist aufgezeigt worden, dass die Ursachen bzw. Gründe für das Scheitern von IT-Projekten immer wieder ähnlich sind^[160]. Oftmals werden unvollständige Anforderungen, unklare Ziele, schlechte Planung und Schätzung, unzureichende Projektmanagementmethoden, fehlende Unterstützung des Managements sowie fehlendes Projektplanungs-Know-How als Gründe angegeben. Lässt sich daraus ableiten, dass die Besonderheiten von IT-Projekten es so schwer machen, diese Projekte erfolgreich abzuschließen?
Wie bereits in der Einleitung dieser Fallstudie erwähnt worden ist, wählen Studenten meist BWL als Studienfach, wenn sie eine Managerkarriere anstreben. Viele Mitarbeiter in der IT-Branche werden als Projektleiter für ein Projekt auserkoren, ohne das nötige Hintergrundwissen hierfür zu besitzen. Das heißt, in Ermangelung geeigneter Projektleiter werden Mitarbeitern diese Tätigkeiten übertragen, die keinerlei Erfahrung mit der Leitung eines Projektes, geschweige denn eines IT-projektes besitzen. Und wie diese Fallstudie zeigt, müssen um ein (IT-)Projekt erfolgreich durchzuführen, zumindest Grundkenntnisse des Projektmanagements vorhanden sein.
Die Entwicklung, Erweiterung und Anpassung von Softwaresystemen zeichnet die meisten IT-Projekte aus. Die größte Besonderheit von Softwareprojekten ist, dass die Ausgangsbasis das Humankapital bildet und kaum bis gar keine anderen Ressourcen eingeplant und berücksichtigt werden müssen. Die Mitarbeiter in den betreffenden Projekten müssen komplexe Zusammenhänge verstehen und umsetzten können. Die Aufgaben dabei zu koordinieren und zu einem erfolgreichem IT-Projekt zu bündeln, ist die Herausforderung des IT-Projektmanagements.
Die IT ist bereits ein wesenlicher Faktor in Unternehmen geworden, dessen Wichtigkeit in Zukunft noch massiv ansteigen wird. In den nächsten Jahren werden mit Hilfe der IT die Geschäftsprozesse weiterhin optimiert werden, die Verzahnung von IT und Unternehmen wird noch stärker werden. Wettbewerb und Globalisierung werden weiterhin große Herausforderungen für ein Unternehemen darstellen und IT-Projekte müssen die an sie gestellten Aufgaben in der gewünschten Zeit und der geforderten Qualität und Leistung erbringen.
Hierfür benötigen Industrie und Wirtschaft weltweit auch weiterhin dringend geschulte und kompetente IT-Projektmanager.

6 Fußnoten

1. ↑ Deutsches Institut für Normung e. V. DIN 69901, Ausgabe 87-08, zitiert in Gaulke, Markus (2002), Seite 9.
2. ↑ Vgl. Kellner, Hedwig (2001), Seite 11f.
3. ↑ Vgl. Mangold, Pascal (2004), Seite 22f.
4. ↑ Balzert, Helmut (2008), Seite 69.
5. ↑ Vgl. Wieczorrek / Mertens (2007), Seite 9.
6. ↑ Vgl. Streitz, Siegfried (2004), Seite 21f.
7. ↑ Vgl. Kellner, Hedwig (2001), Seite 26.
8. ↑ Deutsches Institut für Normung e. V. DIN 69901, Ausgabe 87-08, zitiert in Balzert, Helmut (2008), Seite 18.
9. ↑ Heinrich, Lutz (1997), Seite 10.
10. ↑ Vgl. Mangold, Pascal (2004), Seite 102.
11. ↑ Wieczorrek / Mertens (2007), Seite 13
12. ↑ Winkelhofer, Georg (2005), Seite 11.
13. ↑ Vgl. Bruno, Jenny (2001), Seite 62.
14. ↑ Vgl. Heinrich, Lutz (1997), Seite 10.
15. ↑ Vgl. Wieczorrek / Mertens (2007), Seite 13.
16. ↑ Vgl. Grupp, Bruno (2001), Seite 24.
17. ↑ Vgl. Brandt-Pook et al. (2008), Seite 119.
18. ↑ Vgl. Bruno, Jenny (2001), Seite 58.
19. ↑ Vgl. Durst, Michael (2007), Seite 83.
20. ↑ Vgl. Hofmann / Schmidt (2007), Seite 117.
21. ↑ Wieczorrek / Mertens (2005), Seite 23.
22. ↑ Kitz, Andreas (2004), Seite 37.
23. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 23.
24. ↑ Vgl. Heilmann et al. (2003), Seite 163.
25. ↑ Entnommen aus: Heilmann et al. (2003), Seite 163.
26. ↑ Kitz, Andreas (2004), Seite 37.
27. ↑ Vgl. Heilmann et al. (2003), Seite 163.
28. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 24, Schelle et al. (2007), Seite 99.
29. ↑ Entnommen aus: Schelle et al. (2007), Seite 100.
30. ↑ Wieczorrek / Mertens (2005), Seite 24.
31. ↑ Wieczorrek / Mertens (2005), Seite 24, Schelle et al. (2007), Seite 99.
32. ↑ Wieczorrek / Mertens (2005), Seite 24.
33. ↑ Vgl. Schelle et al. (2007), Seite 99.
34. ↑ Vgl. Schelle et al. (2007), Seite 99.
35. ↑ Wieczorrek / Mertens (2005), Seite 25.
36. ↑ Entnommen aus: Schelle et al. (2007), Seite 101.
37. ↑ Vgl. Schelle et al. (2007), Seite 100.
38. ↑ Wieczorrek / Mertens (2005), Seite 26.
39. ↑ Wieczorrek / Mertens (2005), Seite 26.
40. ↑ Vgl. Schelle et al. (2007), Seite 101.
41. ↑ Entnommen aus: Schelle et al. (2007), Seite 102.
42. ↑ Wieczorrek / Mertens (2005), Seite 27f.
43. ↑ Vgl. Schelle et al. (2007), Seite 102.
44. ↑ Wieczorrek / Mertens (2005), Seite 28.
45. ↑ Vgl. Schelle et al. (2007), Seite 102.
46. ↑ Vgl. Schelle et al. (2007), Seite 103.
47. ↑ Wieczorrek / Mertens (2005), Seite 28.
48. ↑ Wieczorrek / Mertens (2005), Seite 62.
49. ↑ Vgl. Schelle et al. (2005), Seite 113.
50. ↑ Schelle et al. (2005), Seite 113.
51. ↑ Vgl. Schelle et al. (2005), Seite 113.
52. ↑ Vgl. Schelle et al. (2005), Seite 114.
53. ↑ Vgl. Schelle et al. (2005), Seite 114.
54. ↑ Vgl. Schelle et al. (2005), Seite 115.
55. ↑ Vgl. Schelle et al. (2005), Seite 115.
56. ↑ Vgl. Kitz, Andreas (2004), Seite 45f.
57. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 112.
58. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 112.
59. ↑ Vgl. Schelle et al. (2005), Seite 123.
60. ↑ Entnommen aus: Schelle et al. (2005), Seite 121.
61. ↑ Vgl. Schelle et al. (2005), Seite 120.
62. ↑ Vgl. Schelle et al. (2005), Seite 120.
63. ↑ Vgl. Schelle et al. (2005), Seite 120.
64. ↑ Vgl. Schelle et al. (2005), Seite 120.
65. ↑ Vgl. Schelle et al. (2005), Seite 123.
66. ↑ Vgl. Schelle et al. (2005), Seite 123.
67. ↑ Vgl. Schelle et al. (2005), Seite 123.
68. ↑ Vgl. Schelle et al. (2005), Seite 123.
69. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 114.
70. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 63.
71. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 63.
72. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 63.
73. ↑ Schelle et al. (2005), Seite 124.
74. ↑ Angelehnt an: Heilmann et al. (2003), Seite 24f.
75. ↑ Vgl. Heilmann et al. (2003), Seite 24.
76. ↑ Vgl. Heilmann et al. (2003), Seite 25.
77. ↑ Schelle et al. (2007), Seite 175.
78. ↑ Kitz, Andreas (2004), Seite 27.
79. ↑ Vgl. Kitz, Andreas (2004), Seite 27.
80. ↑ Vgl. Kitz, Andreas (2004), Seite 28.
81. ↑ Vgl. Kitz, Andreas (2004), Seite 27.
82. ↑ Vgl. Schelle et al. (2007), Seite 146.
83. ↑ Schelle et al. (2007), Seite 146.
84. ↑ Wieczorek / Mertens (2005), Seite 247.
85. ↑ Kitz, Andreas (2004), Seite 199.
86. ↑ Wieczorek / Mertens (2005), Seite 249.
87. ↑ Kitz, Andreas (2004), Seite 156.
88. ↑ Vgl. Kitz, Andreas (2004), Seite 156.
89. ↑ Vgl. Heilmann et al. (2003), Seite 24.
90. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 198.
91. ↑ Vgl. Kitz, Andreas (2004), Seite 144f.
92. ↑ Vgl. Kitz, Andreas (2004), Seite 145.
93. ↑ Vgl. Kitz, Andreas (2004), Seite 51.
94. ↑ Vgl. Kitz, Andreas (2004), Seite 51.
95. ↑ Kitz, Andreas (2004), Seite 52.
96. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 197.
97. ↑ Vgl. Kitz, Andreas (2004), Seite 148.
98. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 202.
99. ↑ Vgl. Kitz, Andreas (2004), Seite 149, Wieczorrek / Mertens (2005), Seite 202f.
100. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 204.
101. ↑ Vgl. Kitz, Andreas (2004), Seite 151.
102. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 202f.
103. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 206.
104. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 206f.
105. ↑ Vgl. Kitz, Andreas (2004), Seite 155.
106. ↑ Kitz, Andreas (2004), Seite 155.
107. ↑ Vgl. Kitz, Andreas (2004), Seite 155f.
108. ↑ Vgl. Kitz, Andreas (2004), Seite 188.
109. ↑ Vgl. Kitz, Andreas (2004), Seite 188.
110. ↑ DeMarco / Lister (2003), Seite 86.
111. ↑ Vgl. Balzert, Helmut (2008), Seite 360.
112. ↑ Schnorrenberg / Goebels (1997), Seite 6.
113. ↑ Ahrendts / Marton (2008), Seite 9f.
114. ↑ Ahrendts / Marton (2008), Seite 12.
115. ↑ Gaulke, Marcus (2002), Seite 13.
116. ↑ Gaulke, Marcus (2002), Seite 13.
117. ↑ Aktiengesetz § 91 Abs. 2, http://http://bundesrecht.juris.de/aktg/__91.html (18.01.2009, 14:41)
118. ↑ Handelsgesetzbuch § 289 Abs. 1 S. 4, http://bundesrecht.juris.de/hgb/__289.html (18.01.2009, 14:44)
119. ↑ Handelsgesetzbuch § 315 Abs. 1 S. 4, http://bundesrecht.juris.de/hgb/__315.html (18.01.2009, 14:50)
120. ↑ Vgl. Ahrendts / Marton (2008), Seite 911.
121. ↑ Ahrendts / Marton (2008), Seite 11.
122. ↑ Vgl. DeMarco / Lister (2003), Seite 12.
123. ↑ Vgl. Gaulke, Marcus (2002), Seite 49.
124. ↑ Gaulke, Marcus (2002), Seite 43.
125. ↑ Vgl. Bruno, Jenny (2001), Seite 90ff.
126. ↑ Vgl. Gaulke, Marcus (2002), Seite 50, Ahrendts / Marton (2008), Seite 115ff.
127. ↑ Vgl. Streitz, Siegfried (2004), Seite 153.
128. ↑ Vgl. Ahrends / Marton (2008), Seite 129ff.
129. ↑ Vgl. Ahrends / Marton (2008), Seite 133f.
130. ↑ Ahrends / Marton (2008), Seite 134.
131. ↑ Vgl. Ahrends / Marton (2008), Seite 16f.
132. ↑ Vgl. Tiemeyer, Ernst (2005), Seite 113f.
133. ↑ Vgl. Heilmann et al. (2003), Seiten 8 und 193.
134. ↑ Vgl. Gadatsch, Andreas (2003), Seite 192.
135. ↑ angelehnt an Tiemeyer, Ernst (2005), Seite 116.
136. ↑ Vgl. Tiemeyer, Ernst (2005), Seite 196.
137. ↑ angelehnt an Kitz, Andreas (2004), Seite 84.
138. ↑ Vgl. Tiemeyer, Ernst (2005), Seite 132ff.
139. ↑ Vgl. Tiemeyer, Ernst (2005), Seite 137ff.
140. ↑ Blasius, Iris (2004), Seite 13.
141. ↑ Heinrich, Lutz (1997), Seite 43
142. ↑ Wieczorrek / Mertens (2007), Seite 186
143. ↑ Vgl. Kitz, Andreas (2004), Seite 31.
144. ↑ Vgl. Kitz, Andreas (2004), Seite 62.
145. ↑ Vgl. Heilmann et al. (2003), Seite 226, Kitz, Andreas (2004), Seiten 63 und 191.
146. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 105f., Gadatsch, Andreas (2008), Seite 106, IDW PS 850 (2007), Tz. 44f.
147. ↑ Deutsches Institut für Normung e. V. DIN 69901, zitiert in Wieczorrek / Mertens (2005), Seite 243.
148. ↑ Vgl. Heilmann et al. (2003), Seite 138, IDW RS FAIT 1 (2002), Tz. 94ff.
149. ↑ Vgl. Litke, Hans-Dieter (1996), Seite 2, Heilmann et al. (2003), Seite 8.
150. ↑ Vgl. IDW RS FAIT 1 (2002), Tz. 16, 30, 51, 58ff.
151. ↑ angelehnt an die Grafik aus Heilmann et al. (2003), Seite 140.
152. ↑ Vgl. IDW PS 850 (2007), Kitz, Andreas (2004), Seite 91ff. und 196, Wieczorrek / Mertens (2005), Seite 105f., 235f. und 248.
153. ↑ Vgl. IDW PS 850 (2007), Kitz, Andreas (2004), Seite 91ff. und 196, Wieczorrek / Mertens (2005), Seite 105f., 235f. und 248.
154. ↑ Wieczorrek / Mertens (2005), Seite 243f.
155. ↑ Vgl. Wieczorrek / Mertens (2005), Seite 244.
156. ↑ Vgl. Gadatsch, Andreas (2008), Seite 106f., Tiemeyer, Ernst (2005), Seite 128f., Heilmann et al. (2003), Seite 72f.
157. ↑ Vgl. Kitz, Andreas (2004), Seite 97.
158. ↑ Vgl. Gaulke, Marcus (2002), Seite 7.
159. ↑ Vgl. Ahrendts / Marton (2008), Seite V.
160. ↑ Vgl. Gaulke, Marcus (2002), Seite 33ff.

7 Anhänge

7.1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
IT	Informationstechnologie
PM	Projektmanagement
QS	Qualitätssicherung

7.2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Projektmanagement
2	Organisation
3	Einflussprojektorganisation
4	Reine Projektorganisation
5	Matrixorganisation
6	Wasserfallmodell
7	Das "magische Dreieck"
8	Controllingprozess
9	Gegenmaßnahmen und Konsequenzen
10	Projektzeitplan

7.3 Literaturverzeichnis

Ahrendts / Marton (2008)	Ahrendts, Fabian; Marton, Anita: IT-Risikomanagement leben! Wirkungsvolle Umsetzung für Projekte in der Softwareentwicklung, Springer Verlag, Berlin / Heidelberg, 2008, ISBN 978-3-540-30024-3
Balzert, Helmut (2008)	Balzert, Helmut: Lehrbuch der Softwaretechnik: Softwaremanagement, 2. Auflage, Spektrum Akademischer Verlag, Heidelberg, 2008, ISBN 978-3-8274-1161-7
Blasius, Iris (2004)	Blasius, Iris : Risikomanagement in Standardsoftwareprojekten: Die Implementierung integrierter betrieblicher Systeme, Deutscher Universitätsverlag, Wiesbaden, 2004, ISBN 3-8244-2182-8
Brandt-Pook / Kollmeier (2008)	Brandt-Pook, Hans; Kollmeier, Rainer: Softwareentwicklung kompakt und verständlich: Wie Softwaresysteme entstehen, Vieweg + Teubner Verlag, Wiesbaden, 2008, ISBN-13 9783834803658, ISBN-10 3834803650
Bruno, Jenny (2001)	Bruno, Jenny: Projektmanagement in der Wirtschaftsinformatik, 5. Auflage, vdf Hochschulverlag, Zürich, 2001, ISBN-10 3728127914, ISBN-13 978-3-728127914
DeMarco / Lister (2003)	DeMarco, Tom; Lister Timothy: Bärentango mit Risikomanagement Projekte zum Erfolg führen, Hanser Verlag, München [u.a.], 2003, ISBN 3-446-22333-9
Durst, Michael (2007)	Durst, Michael: Wertorientiertes Management von IT- Architekturen, Deutscher Universitäts-Verlag, Wiesbaden, 2007, ISBN 978-3-8350-0895-3
Gadatsch, Andreas (2008)	Gadatsch, Andreas: Grundkurs IT-Projektcontrolling - Grundlagen, Methoden und Werkzeuge für Studierende und Praktiker, 1. Auflage, Vieweg + Teubner Verlag, Wiesbaden, 2008, ISBN 978-3-8348-0469-3
Gaulke, Marcus (2002)	Gaulke, Markus: Risikomanagement in IT-Projekten, Oldenbourg Wissenschaftsverlag, München, 2002, ISBN 3-486-25743-9
Heilmann et al. (2003)	Heilmann, Heidi; Etzel, Hans-Joachim; Richter, Reinhard (Hrsg.): IT-Projektmanagement - Fallstricke und Erfolgsfaktoren, 2. Auflage, dpunkt.verlag GmbH, Heidelberg, 2003, ISBN 3-89864-215-1
Hofmann / Schmidt (2007)	Hofmann, Jürgen; Schmidt, Werner (Hrsg.): Masterkurs IT-Management: Das Wissen für die erfolgreiche Praxis - Grundlagen und beispielhafte Umsetzung - Für Studenten und Praktiker, Vieweg & Sohn Verlag, Wiesbaden, 2007, ISBN 978-3-528-05881-4
IDW RS FAIT 1 (2002)	Institut der Wirtschaftsprüfer in Deutschland e.V.: IDW Reschnungslegungsstandard: Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Informationstechnologie (IDW RS FAIT 1), Düsseldorf, Stand 2002
IDW PS 850 (2007)	Institut der Wirtschaftsprüfer in Deutschland e.V.: IDW Prüfungsstandard: Projektbegleitende Prüfung bei Einsatz von Informationstechnologie (IDW PS 850), Düsseldorf, Stand 2007
Kellner, Hedwig (2001)	Kellner, Hedwig: Die Kunst, IT-Projekte zum Erfolg zu führen: Ziele – Strategien – Teamleistungen, 2. Auflage, Carl Hanser Verlag, München / Wien, 2001, ISBN 3-446-21673-1
Kitz, Andreas (2004)	Kitz, Andreas: IT-Projektmanagement, Galileo Press GmbH, Bonn, 2004, ISBN 3-89842-396-4
Litke, Hans-Dieter (1996)	Litke, Hans-Dieter: DV-Projektmanagement, Hanser Verlag, München / Wien, 1996, ISBN 3-446-18396-5
Lutz, Heinrich (1997)	Lutz, Heinrich: Management von Informatik-Projekten, Oldenbourg Verlag, München, 1997, ISBN 3-486-24046-3
Mangold, Pascal (2004)	Mangold, Pascal: IT-Projektmanagement kompakt, 2. Auflage, Spektrum Verlag, Heidelberg / Berlin, 2004, ISBN 3-8274-1502-0
Schelle et al. (2007)	Schelle, Heinz; Ottmann, Roland; Pfeiffer, Astrid: Projektmanager, 2. Auflage 2005 (Nachdruck 2007), GPM Deutsche Gesellschaft für Projektmanagement e.V., Nürnberg (Nachdruck) 2007, ISBN 3-924841-26-8
Schnorrenberg / Goebels (1997)	Schnorrenberg, Uwe; Goebels Gabriele: Risikomanagement in Projekten: Methoden und ihre praktische Anwendung, Vieweg Verlag, Wiesbaden, 1997
Streitz, Siegfried (2004)	Streitz, Siegfried: IT-Projekte retten: Risiken beherrschen und Schieflagen beseitigen, Carl Hanser Verlag, München / Wien, 2004, ISBN 3-446-22627-3
Tiemeyer, Ernst (2005)	Tiemeyer, Ernst: IT-Controlling kompakt, 1. Auflage, Spektrum Akademischer Verlag, München, 2005, ISBN 3-8274-1620-5
Wieczorrek / Mertens (2005)	Wieczorrek, Hans; Mertens, Peter: Management von IT-Projekten, Springer-Verlag, Berlin / Heidelberg, 2005, ISBN 3-540-22071-2
Wieczorrek / Mertens (2007)	Wieczorrek, Hans; Mertens, Peter: Management von IT-Projekten, 2. Auflage, Springer-Verlag, Berlin, 2007, ISBN 978-3-540-48470-7

7.4 Internetquellen

Aktiengesetz	http://bundesrecht.juris.de/aktg/index.html, Aktiengesetz in der Fassung der Bekanntmachung vom 6. September 1965 (BGBl. I S. 1089), zuletzt geändert durch Artikel 2 des Gesetzes vom 8. Dezember 2008 (BGBl. I S. 2369), (18.01.2009, 14:41)
Handelsgesetzbuch	http://bundesrecht.juris.de/hgb/index.html, Handelsgesetzbuch in der veröffentlichten bereinigten Fassung der Bekanntmachung im Bundesgesetzblatt Teil III, Gliederungsnummer 4100-1, zuletzt geändert durch Artikel 3 des Gesetzes vom 23. Oktober 2008 (BGBl. I S. 2026), (18.01.2009, 14:50)