IT-Projektmanagement -Software im Vergleich

Aus Winfwiki

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

1 Titel

Name der Autoren: Wolfgang Bach, Björn Lüthje, Philipp Naervig-Jensen, Oliver Schlüter
Titel der Arbeit: IT-Projektmanagement -Software im Vergleich
Hochschule und Studienort: FOM Hamburg

2 Vorwort

Diese Arbeit ist eine Gemeinschaftsarbeit der 4 Kommilitonen Wolfgang Bach, Björn Lüthje, Philipp Naervig-Jensen und Oliver Schlüter, welche alle das 6. Semester an der FOM Hamburg im Studiengang Dipl. Wirtschaftsinformatik besuchen. Das Ergebnis der Arbeit wurde in einer Präsentation am 24. Januar 2009 in Hamburg vorgestellt.

3 Einleitung

Projektmanagement ist heutzutage die Grundlage für ein erfolgreiches Projekt. Im Zuge der Globalisierung und immer schneller agierenden Märkten schreitet auch die Komplexität der Projekte immer weiter voran. Die Unterstützung bei dem Projektmanagement wird durch immer weiter entwickelte Projektmanagement Software erweitert. Projektmanagementsysteme von der Einzelplatzversion, über die Webapplikation hin zur Enterprise-Lösung mit der Möglichkeit mehrere tausend Projekte gleichzeitig zu bearbeitet und zueinander in Beziehung zu bringen, ermöglichen einen immer reibungsfreieren Projektablauf.

Die Integration verschiedener Managementsysteme macht die Software immer leistungsfähiger. Angefangen von der Anbindung und der Erweiterung der bestehenden Kommunikationssysteme bis hin zur Integration der Personalmanagementwerkzeuge oder Anbindung des Projektablaufes an Risikomanagementtools, bieten die verschiedenen Softwareprodukte eine immer höher werdende Integrationsdichte.

Der Inhalt dieser Fallstudie staffelt sich in einer kurzen Beschreibung der Grundlagen des Projektmanagements. Danach folgen die Anforderung und deren genauere Beschreibung, an heutige Projektmanagement-Software. Nach Abarbeitung der Grundlagen und den Anforderungen werden verschiedene Softwareklassen betrachtet und im Vergleich gegeneinander beleuchtet.

4 Grundlagen

4.1 Definition von Projekten

Wirtschaftsunternehmen verfolgen den Zweck der Leistungserstellung und/oder den Vertrieb ihrer Produkte oder Dienstleistungen. Sie bewegen sich im Rahmen der Linienarbeit in ihrer Kernkompetenz und erledigen dies mit sich wiederholenden Standardaufgaben. Die Verbesserung der eigenen Kompetenz erreichen Wirtschaftsunternehmen durch Anpassung und Optimierung in Form von Arbeitsteilung und Spezialisierung, um sowohl einen hoheren Output als auch eine höhere Qualität zu sichern.

Externe Einflüsse, wie zum Beispiel neue Technologien, neue staatliche Auflagen oder aber auch Kostendruck durch internationalen Wettbewerb kann ein Unternehmen ebenfalls zur Veränderung zwingen.

Innerhalb von einzelnen Abteilungen eines Wirtschaftsunternehmens werden sogenannte Sonderaufgaben abgewickelt, die sich mit der Anpassung von Prozessen innerhalb einer Abeilung befassen, jedoch nur einen geringen Einfluss auf das gesamte Wirtschaftsunternehmen nehmen und in ihrer Komplexität beschränkt sind. Sie dienen dem Innovationsvorsprung und werden aus der Linienorganisation gesteuert.

Umfangreichere Innovationsaufgaben in Wirtschaftsunternehmen, die aufgrund des Umfanges und des Einflusses über die alltäglichen Aufgaben hinausgehen oder mehrere Personen an einer Aufgabe beteiligt sind, werden als Projekt bezeichnet. Projekte werden durch Aktualität angestossen und entwickeln neue Kompetenzen, neue Produkte und verbesserte Organisationsformen. So definiert das „Deutsche Institut für Normung e.V.“ in der DIN-Norm 69901 ein Projekt wie folgt: 

 "Ein Projekt ist ein „Vorhaben, das im wesentlichen durch die Einmaligkeit 
  der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z.B. Zielvorgabe, 
  zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung 
  gegenüber anderen Vorhaben und projketspezifische Organisation."[1]


Projekte lösen sich von der Linienorganisation und sind durch folgende Merkmale gekennzeichnet:

  • Einmaligkeit und Neuartigkeit des Projektes

Projekte sind einmalige und neuartige Vorhaben zu deren Durchführung nur begrenzt auf vorhandenes Wissen zurückgegriffen werden kann. Der Erfolg eines Projektes ist nicht mit Sicherheit vorherzusagen. Das führt in jedem Projekt zu einer Dynamik, da viele Möglichkeiten ausprobiert werden müssen und somit ein Risiko erzeugen.

  • Zielvorgabe des Projektes

Das Ziel eines Projektes muss messbar sein und anhand von Meilensteinen permanent kontrolliert werden. Meilensteine sind Zwischenziele, die es erleichtern den Projektfortschritt zu kontrollieren. Zudem dienen Meilensteine als motivierend und leichter messbar als das Gesamtprojekt. Die Zielerreichung hat neben dem Kostenrahmen eines Projektes oberste Priorität denn, ein Projekt kann nicht „um jeden Preis“ umgesetzt werden.

  • Zeitlicher Rahmen des Projektes

Der zeitliche Rahmen definiert das Gesamtprojekt, aber auch Einzelaufgaben innerhalb des Projektes, die auf dem kritischen Pfad liegen. Dies sind Einzelaufgaben innerhalb eines Projektes, die bei Verzug den Gesamtfortschritt des Projektes beeinträchtigen.

  • Komplexität des Projektes

Ein Projekt besteht aus verschiedenen Einzelaufgaben. Diese wiederum weisen unterschiedliche Merkmale auf und sind jeweils individuell in ihrer Art, Machbarkeit, Abhängigkeit und dem verfügbaren Budget zu dem Gesamtprojekt. Sie weisen einen hohen Schwierigkeitsgrad und ein Risiko auf. Unscheinbare Aufgaben, die jedoch den kritischen Pfad eines Projektes beeinflussen, können zudem das Gesamtprojekt gefähren und beeinflussen ebenfalls die Komplexität des Projektes.

  • Budget des Projektes

Ein Projekt soll einen Innovationsvorsprung in einem Wirtschaftsunternehmen erzielen. Dieser Vorsprung kann monetär berechnet werden und die Rechenschaft für ein Projekt ablegen. Verspricht ein Projekt nicht einen entsprechenden Erfolg und daraus resultierende Gewinne oder übersteigen die Kosten eines Projektes das geplante Budget, wird das Projekt zu einer Gefahr für das Unternehmen. Kosten müssen somit permanent und für die individuellen Aufgaben im Projekt geplant und kontrolliert.

  • Die Beteiligung mehrerer Ressourcen im Projekt

Aufgrund der Komplexität und der bereichs- und fachübergreifenden Themen, stellen Projekte häufig Aufgaben dar, deren Planung und Umsetzung über verschiedenen Abteilungen reichen und Ressourcen mit entsprechenden Fachkenntnissen erfordern. Diese Ressourcen sind generell limitiert. Zudem verlangt ein Projekt meist nach den besten verfügbaren Ressourcen im Unternehmen und läuft somit gegen die Interessen der Linie. Die Arbeit in interdisziplinären Teams macht eine einheitliche Arbeitsmethodik innerhalb des Teams notwendig und erfordert selbstständiges Denken und Handeln, die Möglichkeit Probleme zu lösen sowie Flexibilität und das Denken in Zusammenhängen.

Unterschiedliche Projekttypen können wie folgt klassifiziert werden:

Projekttypen Inhalt, Ergebnis
Studien, Expertisen Wirtschaftliche und technische Erkenntnisse über Aufgabenstellung und Realisierbarkeit
Neue Produkte Neues Produkt wird erarbeitet und im Markt eingeführt
Produktanpassungen Produkt wird an die neuen Bedürfnisse angepasst
Anlagenbau Installation neuer technischer Anlagen zu vereinbarten Terminen und Kosten
Rationalisierung Kostenreduktion, Ertrags-/Leistungssteigerung
Organisationsentwicklung Anpassung der Organisation/Abteilung/Bereich an die neuen Erfordernisse des Unternehmens/Marktes
EDV Einführung eines DV-Systems
Tabelle 1: Aufgaben mit Projektcharakter[2]


Erreicht ein Projekt das vorgegebene Ziel nicht innerhalb des definierten Zeitrahmens oder innerhalb des vorgeschriebenen Budgets, gilt das Projekt nicht automatisch als misslungen. Erst wenn mehrere Bedingungen nicht erfüllt sind, wird von einem Misserfolg gesprochen.

Zudem erfordern Projekte von den Beteiligten ein überdurchschnittliches Engagement, da ein erfolgreiches Projekt einem Wirtschaftsunternehmen meist einen Wissensvorsprung bringt. Um sicherzustellen, das ein Projekt etwas besonderes darstellt und in seiner Wichtigkeit nicht verwässert, muss die Auswahl von Projekten beschränkt sein.

Abb.1: Aufgaben in Wirtschaftsunternehmen
Abb.1: Aufgaben in Wirtschaftsunternehmen[3]


Folgende Vorteile können sich durch ein Projekt ergeben:

Direkte Einsparungen:

  • Personal, Miete, Service, Material
  • Reduzierte Kapitalbindung, Durchlaufzeiten

Vermeidbare Kosten

  • Weniger zusätzliches Personal und Service bei höheren Arbeitsvolumen
  • Reduzierung von Lager-, Transport,- Liquidations-, und Kapitalbindungskosten

Höhere Einnahmen

  • Schnelleres Fakturieren
  • Bessere Kontrolle über das Mahnwesen
  • Schnellere Auslieferung und damit höherer Umsatz

Nicht quantifizierbarer Nutzen

  • Erhöhte Transparenz der Geschäftsprozesse
  • Exakte und schnellere Disposition
  • Fehlervermeidung
  • Werbeeffekt, Imagesteigerung, verbesserte Kundenzufriedenheit und Ablauforganisation, geringere Personalabhängigkeit

4.2 IT-Projektmanagement

Fortschreitende Globalisierung im Bereich der Marktwirtschaft fördert den verstärkten Einsatz des Projektmanagements. Unternehmen bedienen sich dieses Werkzeugs um anspruchsvolle Aufgabenstellungen zügig und wirtschaftlich umsetzen zu können. Projektmanagement ist ein allumfassender Prozess zur Erreichung komplexer Zielvorgaben. Es ist untergliedert in die Bereiche Organisation, Planung, Steuerung und Überwachung aller Aufgaben und Ressourcen, die während der Umsetzung des Projekts benötigt werden. Projektmanagement kann einen signifikanten Beitrag dazu leisten, dass Projekte erfolgreich sind.

Die Gründe für ein Projektmanagement sind u.a.

  • Zielorientiertes Arbeiten im Rahmen der Projekte
  • Verstärkte Professionalisierung von Projekt- und Teamarbeit
  • Verminderung von Risiken
  • Verbesserter Informationsfluss und –austausch
  • Bessere Planung unter Beachtung von Ressourcen und Terminen
  • Überwachung von Projektfortschritten

Als Projektmanagement wird die Gesamtheit aller Tätigkeiten bezeichnet, mit denen Projekte geplant, überwacht und gesteuert werden. Einige Institutionen und Organisationen definieren Projektmanagement im Detail unterschiedlich. Das wird an diesen Beispielen deutlich.

  • Project Management Institute (PMI): “Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements”.
  • DIN-Norm (DIN 69901): „Projektmanagement ist die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes“.
  • Gesellschaft für Informatik: „Das Projekt führen, koordinieren, steuern und kontrollieren.“

Auf internationaler Ebene gibt es zwei nennenswerte Verbände, die sich dem Thema Projektmanagement verschrieben haben:

  • Project Management Institute (PMI)
  • International Project Management Association (IPMA)

Das PMI hat sich auf US-amerikanischer Ebene etabliert und vertritt die Interessen von Projektleitern. Es ist Herausgeber des Project Management Body of Knowledge (PMBOK 2003) welches als ANSI und IEEE-Standard anerkannt ist. Die nationalen PM-Organisationen werden weltweit durch den seit 1969 bestehenden Dachverband „International Project Management Association“ (IPMA) vertreten, dessen Ziel eine „länderübergreifende Weiterentwicklung, Standardisierung und Harmonisierung“[4] des Projektmanagements ist. Die Grundlage dafür stellt die PM-Zertifizierung mit dem Namen IPMA Competence Baseline (ICB) dar. Die ICB ist jedoch weniger ein Lehrbuch, sondern eine Sammlung von Kompetenzbereichen und eine Zusammenführung von Begriffen, Methoden und Funktionen. Ziel der ICB ist es, den Lesern den Zugang zum Wissen, zur Erfahrung und zum persönlichen Verhalten im Projektmanagement zu vermitteln.[5].

Die deutsche Vertretung der IPMA ist die 1979 gegründete Gesellschaft für Projektmanagement (GPM). Die GPM ist für die „Verbreitung und Förderung des Gedankenguts des Projektmanagements, die Wissens- und Erfahrungssicherung sowie die Weiterentwicklung und Knowhow-Transfer im Projektmanagement z.B. durch die Aus- und Weiterbildung oder durch neutrale Kompetenzbestätigungen von Projektpersonal zuständig [6]. Zusammen mit dem Rationalisierungs- und Innovationszentrum der Deutschen Wirtschaft (RKW) hat die GPM einen PM-Lehrgang mit Abschluss „Projektmanagement-Fachmann (RKW/GPM)“ entwickelt. Das Lehrbuch „Projektmanagement-Fachmann (PMF 1999)“ und die „die in dreißigjähriger Arbeit beim DIN entwickelten Normen zur Projektwirtschaft“[7] stellen das Fundament der Ausbildung dar.


Zentraler Bestandteil von Projektmanagement sind Techniken in Form von Methoden und Verfahren, wie z.B. Gantt-Diagramm, Balkenplan, Netzplanverfahren, Meilenstein-Trend-Analyse. Diese Werkzeuge ermöglichen genauere Vorgaben zur Planung und Durchführung von Projekten in Hinblick auf Zeitdauer, Kostenaufwand und Qualitätseinschätzung.


Die Organisation von Projekten spielt eine grundlegende Bedeutung. Nach Heeg[8] unterscheidet man in der Aufbauorganisation zwischen folgenden Typen.


Reine Projektorganisation Projektkoordination (Stab-Projekt-Organisation) Matrix-Projektorganisation
Beschreibung
  • Projektmitarbeiter werden für die Dauer des Projektes aus der bestehenden Unternehmensorganisation vollständig freigestellt (Task Force)
  • Erweiterung des Aufgaben-, Kompetenz(fachlich und disziplinarisch) und Verantwortungsbereich des PL
  • Für umfangreiche und wichtige Projekte ist diese Projektorganisation gut geeignet
  • Bestehende Organisation bleibt fast unverändert
  • PL führt eine Stabsstelle und besitzt keine Weisungsbefugnis gegenüber den funktionalen Abteilungen
  • PL koordiniert den Projektverlauf in terminlicher, kostenmäßiger und sachlicher Hinsicht
  • PL als Koordinator -> sammelt und verteilt Informationen
  • PL ist verantwortlich für Reporting, Informationsfluss, Qualität der Ergebnisse
  • Zeitlich befristete Verteilung der Autoritäten zwischen der Unternehmensorganisation und der Projektorganisation (Überlagertes Mehrliniensystem)
  • Mischung aus Reiner- und Stab-Linien Projektorganisation
  • PL hat teilweise Weisungsbefugnis gegenüber den Projektmitarbeitern solange es Aufgaben im Rahmen des Projekts betrifft
  • MA sind zwar weiterhin dem Linienvorgesetzten unterstellt, parallel aber auch dem PL zugewiesen
  • Projekt- und Abteilungsbezogene Entscheidungen werden gemeinsam vom PL und Abteilungsleiter gefällt
  • Relativ häufig verwendete Projekt-Organisationsform
Vorteile
  • PL kann über die Projektressourcen schnell und einfach verfügen
  • Projektmitarbeiter können sich vollkommen dem Projekt widmen (Gesteigerte Leistung und Effizienz)
  • Schnelle Reaktion auf Veränderungen innerhalb des Projektes möglich
  • Kaum organisatorische Umstellungen (kostengünstig)
  • Nutzung von Ressourcen, Techniken, Know-how und Erfahrungen der funktionalen Abteilung
  • Konzentration auf fachspezifisches Problem
  • Mitarbeiter können auch parallel in mehreren Projekten tätig sein
  • Optimale Kapazitätsauslastung (Ressourcenverteilung auf Linien- und Projekttätigkeit)
  • Geringe Umstellungskosten
  • Kreativität und Wissen der Projekt-Mitarbeiter kann genutzt werden
Nachteile
  • PL hat keinen Zugriff auf Ressourcen außerhalb der Projektorganisation
  • Unter- bzw. Überbelastung der Projektmitarbeiter möglich
  • Kosten durch Anpassung der Organisation
  • Teilweise Umstellungsschwierigkeiten der Projektmitarbeiter bei Ein- und Ausgliederung aus dem Projekt
  • Relativ schwache Position des PL (Widerstand möglich)
  • In Krisensituation des Projekts werden die übergeordneten Instanzen überlastet
  • Zeitlicher Aufwand durch fehlende Weisungsbefugnis des PL
  • Langwierige Entscheidungsfindung möglich
  • Vergrößertes Gesamtrisiko durch Dezentralisierung
  • Starke Kontrollinstanz nötig
  • Konflikte durch Mehrliniensysteme möglich
  • Doppelbelastung der Mitarbeiter im Projekt erfordert hohe Selbständigkeit und Belastbarkeit
  • Mitarbeiter müssen über Teamgeist und Fairness gegenüber Mitarbeitern, PL und Vorgesetzten verfügen.
Skizze
Abb.2: Reine Projektorganisation
Abb.2: Reine Projektorganisation
Abb.3: Projektkoordination (Stab-Projekt-Organisation)
Abb.3: Projektkoordination (Stab-Projekt-Organisation)
Abb.4: Matrix-Projektorganisation
Abb.4: Matrix-Projektorganisation

Tabelle 2: Formen der Projektorganisation

Abb.5: Aufgaben des Projektmanagement
Abb.5: Aufgaben des Projektmanagement



Die Auswahl der geeigneten Projektorganisation sollte gemeinsam zwischen PL und Auftraggeber getroffen werden. In der Praxis jedoch „entscheidet nicht selten der Auftraggeber ohne größere Abklärungen“[9]. Parallel zur Aufbauorganisation von Projekten muss auch die Ablaufstruktur von Projekten definiert werden. Nach Burghardt [10] bestehen die Hauptabschnitte in Projekten aus den Phasen:


1. Projektdefinition

2. Projektplanung

3. Projektkontrolle

4. Projektabschluss


Abb.6: Der PM-Regelkreis
Abb.6: Der PM-Regelkreis[10]

Neben den steuernden Aktivitäten ist vor allem das Erkennen von Abweichungen wichtig, um das Erreichen des Projektziels nicht zu gefährden. Hier unterstützt das Modell des PM-Regelkreises (Siehe Abb.6), in welcher die Zusammenhänge zwischen Planung und Kontrolle überprüft werden.Während der Projektdurchführung werden durch die Projektkontrolle die vorhandenen Ist-Werte mit den geplanten Soll-Werten verglichen. Bei Abweichungen werden durch die Projektsteuerung entsprechende Maßnahmen eingeleitet. Ziel sollte sein, die Planabweichungen möglichst zeitig zu erkennen „um rechtzeitig korrigierende Maßnahmen einleiten zu können, ohne dass tatsächlich Plankorrekturen vorgenommen werden müssen.“[11]

4.3 Software als Werkzeug

Die Überwachung und das komplette Management von Projekten ist grundsätzlich auch ohne einen speziellen Softwareeinsatz möglich. Gewinnt ein Projekt jedoch schnell an Komplexität, bzw. ist diese dem Projekt bereits vorbestimmt, kann Projektmanagementsoftware unterstützen die Gesamtübersicht zu bewahren und dem Projekt letztlich helfen, effizient zu bleiben.

5 Anforderungen an IT-Projektmanagement-Software

IT-Projektmanagement-Software beschäftigt sich mit der strukturierten Überwachung und kann generell gresprochen ein Projekt allein nicht erfolgreicher machen. Jedoch hilft es bei der Organisation und Verwaltung von Ressourcen innerhalb des Projektes. Es ermöglicht ferner zu jedem Zeitpunkt eine Aussage zu treffen auf die Fragen:

  • Welche Ressourcen sind im Einsatz bzw. werden benötigt?
  • Reicht das Budget aus und wie ist es verteilt?
  • Welche Aufgaben beeinflussen den kritischen Pfad?
  • Welches sind die nächsten Schritte im Projekt?
  • Wie hoch ist die Wahrscheinlichkeit auf einen Erfolg?


IT-Projektmanagement-Software stellt somit ein Werkzeug dar, dass die unterschiedlichen Dimensionen einen Projektes visualisiert und Warnmechanismen verwendet, um auf Verzögerungen, mangelnde Ressourcen oder ein Überschreiten des Budgets hinzuweisen. Dabei bietet IT-Projektmanagement-Software zum Teil bereits Kommunikationstools und zentrale Datenspeicherung für Dokumente, um den gesamten Projektverlauf zu dokumentieren und ein einheitliches Arbeitsumfeld für alle Beteiligten zu schaffen. Dies mindert Reibungsverluste aufgrund unterschiedlicher Formate und Standards innerhalb eines Projektes.

Nach Projektmagazin.de[12] gibt es u.a. folgende Kriterien zur Projektmanagement-Software-Beurteilung:

  • Projektstrukturierung
  • Netzplantechnik
  • Ressourcenmanagement
  • Kostenmanagement
  • Aufwandserfassung
  • Controlling
  • Finanzmittelmanagement
  • Reporting
  • Präsentation
  • Multiprojektmanagement
  • Projektportfoliomanagement
  • Projektorganisation
  • Informationsmanagement
  • Risikomanagement
  • Schnittstellen

Im Rahmen dieser Fallstudie sollen einige Kriterien näher betrachtet werden und die Anforderungen an PM-Software-Systeme unterschieden werden.

5.1 Zentralisierte Dokumentation

Projekte bestehen aus zum Teil komplexen Aufgaben, deren Lösungen individuell und meist aufwendig erarbeitet werden müssen. Um diese Arbeit effektiv nutzen zu können und im Fall des Ausfalles einzelner Ressourcen diese Schritte nicht umständlich neu zu recherchieren, müssen alle Schritte in einem Projekt dokumentiert und zentral und auf einem für alle beteiligten und relevanten Personen zugänglichen System abgelegt werden. Dies erleichtert die Stellvertretung von Projektmitarbeitern bei Abwesenheit oder Krankheit. Der bereits aufwendig erarbeitete Prozess kann nachgelesen und jederzeit standardisiert wiederholt werden. Dokumentation ist ferner ein Bestandteil der Qualitätssicherung und stellt sicher, dass zu jedem Zeitpunkt nachvollzogen werden kann, wie das Projekt oder Aufgaben entstanden sind und was dabei zu beachten ist.

Die Dokumentation sollte alle Aufzeichnungen in Form von Zeichnungen, Mitschriften, und Planungen beinhalten, die den Verlauf des Projektes dokumentieren und einzelne Aufgaben beschreiben.

5.2 Unterstützung der internen Kommunikation

Die interne Kommunikation in einem Projekt ist massgeblich am Erfolg der Aufgaben beteiligt. Aufgrund von immer umfangreichen Aufgaben in Unternehmen und der stetigen Globalisierung, müssen Projektteams z.T. über mehrere Kontinente und in unterschiedlichen Sprachen und Zeitzonen kommunizieren. Das wiederum bringt Zeitverzögerung und Informationsverluste mit sich. Das Medium Email bietet hier bereits eine gute Möglichkeit, kann zudem jedoch durch die Kommunikation über eine IT-Projektmanagement-Software verbessert werden. So wird die Kommunikation entsprechend des Themas oder der Aufgabe zu dem Projekt ablegt und wieder auffindbar gemacht.

Die Kommunikation in einem Projekt muss ferner neu organisiert werden. So müssen projektweit klare Standards für unterschiedliche Entscheidergruppen und Dringlichkeitsklassen definiert und global benutzt werden, denn oft kann ein einzelnes Projektmitglied nicht die Reichweite der Änderung einer Aufgabe überblicken und gefährdet den Kritischen Pfad eines Projektes und somit den gesamten Projekterfolg. Zudem ist die klare und sachliche Kommunikation in einem Projekt wichtig, die keine Interpretation offen lässt.

5.3 Ressourcenverwaltung

Abb.7: Aufgaben in Wirtschaftsunternehmen
Abb.7: Aufgaben in Wirtschaftsunternehmen[13]

Ein Projekt erfordert aufgrund der unterschiedlichen Aufgaben, auch unterschiedlich qualifizierte Personen - im folgenden Ressourcen genannt. Dazu stellt sich die Frage, wer welche Rolle in einem Projekt oder einer Aufgabe einnehmen soll. In einem Projekt spielt die Hierachie eine unwesentliche Rolle, jedoch werden Projektentscheider meist nach dem Kriterium Macht und Teammitglieder nach ihrer fachlichen Kompetenz ausgewählt. Aufgrund der Tatsache, dass in der Regel die Mitarbeiter mit den besten Fachkenntnissen aus der Linie genommen werden, trifft ein Projekt nicht immer auf Zuspruch innerhalb des Unternehmens.[14]


5.3.1 Konfigurationsmanagement

Konfigurationsmanagement (KM) ist „eine Managementdisziplin, die organisatorische und verhaltensmäßige Regeln auf den Produktlebenslauf einer Konfigurationseinheit von seiner Entwicklung über Herstellung und Betreuung anwendet“[15]. Konfiguration sind vollständige technische und fachliche Beschreibungen und Definitionen von Produkten inklusive der verwendeten Software, Hardware, oder Dienstleistung(en). Hauptaufgabe des Konfigurationsmanagement ist die Sicherstellung das eine Konfigurationseinheit über seine funktionalen und äußeren Merkmale zu jedem Zeitpunkt eindeutig identifizierbar ist. Ziel dieser zeitlich genauen Identifikation ist die „Kontrolle von Änderungen zur Sicherstellung der Integrität, auch während der Nutzung des Produktes“[16]. Es soll also mithilfe von KM sichergestellt werden, dass zu jedem Zeitpunkt auf vorhergehende Versionen zurückgegriffen werden kann.

Weitere Ziele nach Versteegen[17] aus der Definition des CMMI:

  • Steuerung der Änderung von funktionalen und physischen Eigenschaften der Konfigurationseinheiten
  • Aufzeichnung und Veröffentlichung von Änderungs- und Implementierungsstati
  • Verifikation der Erfüllung von spezifizierten Anforderungen

Besonders im IT-Bereich und dort speziell in der Softwareentwicklung wird auch allgemein von Software-Konfigurationsmanagement gesprochen, welches nach Babich „ein Verfahren zur Identifikation, Organisation und Überwachung von Änderungen an Software“ darstellt.

Im Bereich der Softwareentwicklungsprojekte sollte das Konfigurationsmanagement durch das PMS unterstützt werden. Im Zusammenhang mit Projektmanagement –Software die den KM-Prozess unterstützen, spielen nach Versteegen[17] weitere Teilprozesse nach dem Schema Build -> Test -> Release -> Distribute eine Rolle:

Versionsverwaltung

  • Grundfunktion aller SCM-Tools
  • Datenbasis ist das KM-Repository
  • Check-Out, Bearbeitung und Check-In durch Entwickler
  • Erstellung einer neuen Version beim Check-In
  • Die Versionierung erfolgt nur auf Basis der Konfigurationseinheiten, nicht der gesamten Konfiguration

Konfigurationsverwaltung

  • Ermöglicht Gruppierung der Konfigurationseinheiten zu Konfigurationen
  • Bildung einer Hierarchie der Konfigurationen
  • Konzept für die Berechtigungen der Benutzer (Erstellung, Gruppierung, Änderung von Konfigurationseinheiten und Konfigurationen)

Releasemanagement

  • Zeitliche, inhaltliche Planung von Releaseständen
  • Möglichkeit zum Einfrieren der Gesamtkonfiguration nach Auslieferung des Release (Baselining)
  • Nachvollziehbarkeit des Ursprungs jeder Konfigurationseinheit möglich

Änderungsmanagement

  • Änderungen an Konfigurationen werden durch einen definierten Prozess eingeleitet
  • Änderungen (Change Request) müssen über Anträge dokumentiert, bewertet und genehmig (oder abgelehnt) werden
  • Nach Genehmigung wird die zeitlich und technische Implementierung der Änderung geplant
  • Nach der Planung werden die, von der gewünschten Änderung betroffenen, Konfigurationseinheiten bearbeitet und an das Buildmanagement übergeben

Buildmanagement

  • (Re)Produzierbarkeit von Konfigurationseinheiten durch einen Buildprozess
  • Auch die Tools (Compiler, Analyzer, Linker) die den Buildprozess unterstützen sollten durch das Konfigurationsmanagement verwaltet werden
  • Regelmäßige Erstellung von Builds (Nightly, Weekly, etc.)
  • Erstellung sollte komplett automatisiert werden (Keine Beeinträchtigung bei Personalausfall)
  • Eine eigenständige Build-Umgebung (Build-PC) reduziert Risiken und gewährleistet die Lauffähigkeit der Build-Prozesse

Distributionsmanagement

  • Sicherstellung der Verteilung und Aktivierung von Softwareprogrammen
  • Möglichkeiten der Push-Technologie (Aktive Verteilung an Empfänger) oder Pull-Technologie (Anwender holt sich die Einheiten)
  • Bei Mehrschicht-Architekturen muss die Verteilung bei einem neuen Release synchron auf allen Schichten erfolgen
  • Sicherstellung der Verteilung der Releases durch Records (Aufzeichnung von Empfänger, Datum und Release-ID)

5.3.2 Skill-Management

Das „Skill Management beschäftigt sich mit dem Wissen in den Köpfen“ [18] Die projektorientierte Ausprägung heutiger Unternehmen erfordert eine gezielte Übersicht über die Fähigkeiten (engl. skills) und Kompetenzen. Genau dies ist die Hauptaufgabe des Skillmanagements (SM). Das SM verwaltet die Informationen über die Kompetenzen der Mitarbeiter und deren gezielte Weiterentwicklung im Sinne des Unternehmens. Die Mitarbeiter der Unternehmen haben heutzutage ständig wechselnde Aufgaben durch immer neu zu bearbeitende Projekte. Die Unternehmen stehen im Zuge der Globalisierung vor neuen Herausforderungen und immer höherem Innovationsdruck durch die schnelle Entwicklung des Marktes. Dadurch bedingt müssen sich die Mitarbeiter immer wieder neues Wissen aneignen und den Wissenshorizont erweitern. Vor allem die Ausbildung sozialer Kompetenzen ist im Zeitalter der neuen Medien und Kommunikationswege sehr wichtig[19]. Im Rahmen der Erweiterung in ausländische Märkte ist auch die Erweiterung der Sprachkenntnisse der Mitarbeiter immer wichtiger. [20]

„Jedes Problem in einem Unternehmen ist letztlich ein Personalproblem“ [21]

Mit diesem Satz beschreibt A. Herrhausen indirekt auch die Gewichtung des Mitarbeiters in einem Projekt. Ein Projekt hängt letztlich von den Kompetenzen der Projektmitarbeiter ab.

Ist das Know How für das Projektziel im Mitarbeiterkreis nicht vorhanden, so ist der erfolgreiche Abschluss des Projektes nicht gewährleistet. Daher ist es notwendig, dem Projektverantwortlichen im Projektmanagementsystem ein Werkzeug zur Verfügung zu stellen, welches sich um die Verwaltung dieser Informationen kümmert. Diese Aufgabe übernimmt das Skillmanagement.

Diese Systeme sind jedoch nicht direkt Teil des Projektmanagementsystems, sondern sind meist an die Human Resources (HR) Systeme der Unternehmen angekoppelt. Das PMS muss also die Aufgabe der Anbindung der vorhandenen Daten in das Projektmanagement übernehmen. Durch den automatischen Abgleich zwischen Anforderungen und vorhandenen Kompetenzen ermöglicht eine PMS mit Anbindung an das Skillmanagementsystem die optimale Zuordnung der Mitarbeiterressourcen im Projekt und kann damit den Projekterfolg entscheidend unterstützen..

Zu den von einem Skillmanagementsystem verwalteten Daten gehören z.B.
  • Referenzen
  • Trainings/Weiterbildungen
  • Projekt-Erfahrungen
  • Tätigkeitskataloge
  • Sprachkenntnisse

5.3.3 Kostenmanagement

Unter Kostenmanagement versteht man die Ermittlung und Zuordnung der voraussichtlichen Kosten für die Projektteilaufgaben unter Berücksichtigung der vorhandenen Einschränkungen und der gewünschten Ziele. Projektkosten bilden die Grundlage des Kostenmanagements. Gemeint ist damit die Summe aller Kosten die aus den Tätigkeiten des Projektes resultieren und der zusätzlichen Systeminvestitionskosten.

Ziele des Kostenmanagements:[22]

  • Ermittlung des Projektbudgets
  • Grundlage für die Kalkulation eines Angebots von externen Projekten
  • Grundlage der Überwachung der Projektkosten

Projektkosten sind einmalig, bezogen auf die Charakteristik eines Projektes mit definierten Anfang und Ende. Die Kosten können in fixe und variable Projektkosten unterschieden werden.

Variable Projektkosten: Fallen bei Durchführung geplanter Projektmaßnahmen an.

Fixe Projektkosten: Unabhängig von der Durchführung der Projektmaßnahmen.

Im späteren Verlauf der Projektdurchführung nicht mehr beeinflussbar. Bestimmung der Kosten nach fix oder variabel sollte während der Budgetierung erfolgen. Die Möglichkeit der Anpassung von Budgets wird dadurch einfacher. Einflussfaktoren auf Projektkosten können sein:

  • Anspruch der Aufgabenstellung, bzw. Anforderungsspezifikation
  • Größe des Projektes
  • Schwierigkeitsgrad
  • Anforderungen an:
    • Zuverlässigkeit
    • Sicherheit
    • Dokumentation
    • Mehrsprachigkeit
  • Entwicklungswerkzeuge
  • Anzahl, Erfahrung und Motivation der Mitarbeiter
  • Zeitrahmen

Um die Projektkosten besser analysieren und überblicken zu können, werden Sie in Projektkostenarten unterteilt. Gemeint ist damit die Gliederung der Kosten des Projektes nach Technik, Arbeitsteilung und kalkulatorischen Gegebenheiten.

Beispiele für Kostenarten:

  • Ausgabenwirksam (Direkter Mittelabfluss)
  • Intern (Nur Kalkulatorisch)

Und:

  • Einmalig
  • Wiederkehrend

Bei einigen Kosten (z.B. Hardware, Software, Infrastruktur, Material, Personale, etc.) kann die Zuordnung sowohl bei einmaliger Kostenart, als auch bei wiederkehrend vorgenommen werden. In diesem Fall müssen die Kosten zeitlich abgegrenzt u8nd entsprechend zugeordnet werden. Alle Kosten sollten einer Projektkostenstelle zugeordnet werden. Eine Projektkostenstelle ist ein abgegrenzter Verantwortungsbereich, im Rahmen eines Projektes, der sich mit den Projektkosten befasst. In IT-Projekten bezieht sich ein relativer hoher Kostenfaktor auf die verwendeten Zeiteinheiten der Mitarbeiter. Für die Planung ist deshalb der Kostensatz pro Personentag wichtig. Bei der Ermittlung der Projektpersonalkosten wird zwischen zwei Ansätzen unterschieden:

  • Nettoansatz: Reine Personalkosten pro Zeiteinheit
  • Bruttoansatz: Personalkosten + Kosten für die Nutzung der Infrastruktur (Arbeitsplatz, Arbeitsmittel, Umlagen etc.)


Projektkostenplanung ist eine Teilaufgabe des Kostenmanagements und basiert auf einer einsatzmittelbezogene Aufwandsschätzung pro Arbeitspaket. Nach Jenny[23] ist die Kostenplanung die letzte Phase der Projektplanung. Danach sind weitere grundlegende Projekt-Entscheidungen möglich (Make or buy, Empirisches oder konzeptionelles Vorgehen, zentrale oder dezentrale Lösung, etc.). Die Grundlage für die Projektkostenplanung bildet der Projektkostenplan. Die Erstellung ist für den PL eine der schwierigsten Planungsaufgaben. Am Anfang des Projektes verfügt er über unvollständige Daten und Schätzwerte, die das Projekt betreffen. Auch die Planung des Verlaufs der Projektdurchführung wird mit zunehmender Projektdauer und Komplexität ungenauer. Hinzu kommen externe Faktoren, wie Entwicklung der Gesamtwirtschaft oder Entwicklung neuer Technologien. Die Grundlage für die Projektkostenplanung bilden folgende Daten:

  • Arbeitspakete aus dem Projektstrukturplan
  • Ergebnisse der Einsatzmittelplanung von Betriebsmittel und Personal (Menge, Dauer, Qualität)
  • Ergebnisse der Organisationsplanung (Projektorganisationsform, Anzahl der Projektmitglieder, Funktionen)
  • Geplante Investitionskosten (Systemkosten) für die Anpassung der Infrastruktur


Ziele der Projektkostenplanung:

  • Optimierung der Termin- und Kostenkontrolle
  • Ermittlung der gesamten Projektkosten
  • Ermittlung exakter Kontrollwerte durch Gliederung in Kostenarten
  • Ermöglichung der Unterteilung der ermittelten Entwicklungskosten in
    • Betriebsmittelkosten
    • Personalkosten
  • Erneute Überlegungen über den Nutzwert des Projekts aus Kostensicht (Sinnhaftigkeit des Projekts)
  • Kosten-Nutzen-Analyse


Verhältnis Kosten-Nutzen-Analyse

Jedes Projekt sollte auf seine Wirtschaftlichkeit geprüft werden. Je komplexer und teurer ein Projekt wird, desto hilfreicher ist es mithilfe einer Kosten/Nutzen-Analyse den Entscheidungsträgern die ermittelten Daten zu präsentieren. Die Möglichkeit eines PMS die geschätzten Projektkosten mit dem Projektnutzen gegenüberzustellen ist eine gute Möglichkeit die Wirtschaftlichkeit des Projektes zu ermittelnJe genauer die Aufwandsschätzung erfolgt, desto genauer kann die Kosten/Nutzen-Analyse durchgeführt werden. Die Analyse kann auf Grundlage folgender Investitionsrechnung erfolgen.[24]

Kostenvergleichsrechnung

  • Gegenüberstellung zweier oder mehr Varianten der anfallenden Kosten einer Periode (i. d. R. ein Jahr)

Gewinnvergleichsrechnung

  • Vergleich der zu erwartenden Jahresgewinne und der Investitionen
  • Auswahl der Investitionen mit dem höheren Jahresüberschuss

Rentabilitätsrechnung (ROI)

  • Return-on-Invest-Rechnung (ROI) ermittelt den durchschnittlichen Jahresgewinn auf das investierte Kapital

Amortisationsrechnung

  • Ermittlung des Zeitpunkts, an dem die Einnahmen die Investitionssumme erreicht haben (Break-even-point)

5.4 Controlling von IT-Projekten

Das Projekt-Controlling dient der Überwachung von Zeit, Kosten und Ressourcen in Projekten. Da diese Werte entscheidend für den Erfolg eines Projektes sind, ist ein Controlling und Reporting für die Entscheider von hohem Interesse. Nach Landau und Hellwig ist "ein Projekt-Management-Office für die Bereitstellung der Projektinfrastruktur zuständig und übernimmt das Projekt-Controlling. Dagegen konzentrieren sich Assignmentmanager und Ressourcenmanagement- Abteilungen ausschließlich auf die Kapazitätszuteilung und die Lösung von Ressourcenkonflikten“.[25]

Nach Beiderwieden[26] können folgende Arten des Projektcontrollings unterschieden werden.

  • Termin- und Ablaufcontrolling
  • Kostencontrolling
  • Ergebniscontrolling (Qualitätssicherung)

5.4.1 Status Reporting

Projeke, die aus unterschiedlichen Teams zusammengesetzt sind und zum Teil über mehrere Kontinente miteinander arbeiten, benötigen regelmäßige und standortübergreifende Projektinformationen. Informationen, die ihnen ermöglichen Abhängigkeiten zu anderen Aufgaben zu erkennen und entsprechend zu handeln. Da diese Abhängigkeiten zum Teil den kritischen Pfad eines Projektes und somit den Erfolg beeinflussen, ist eine Berichterstattung für alle Projektmitglieder und Entscheider über alle Grenzen hinweg unabdingbar. Status Reporting befasst sich mit den kritischen Themen in solchen Projekten. Projekte sind prozessorientiert und durchlaufen definierte Phasen, welche wiederum durch Meilensteine abgeschlossen werden:

1. Phase: Definition (Projektidee, Teambildung)
2. Phase: Planung (Analyse, Zielsetzung, Lösungssuche)
3. Phase: Realisation (Durchführung)
4. Phase: Abschluss (Auswertung, Abschluss, Folgeprojekte)[27]


Diese Phasen werden nicht linear, sondern zirkulär durchlaufen.

Status Reporting befasst sich mit der regelmäßigen Berichterstellung von Aufgaben innerhalb eines Projektes. Abhängig von der Größe eines Projektes und den kritischen Meilensteinen, entstehen messbare Werte, die den Projektverlauf beschreiben. Bestandteile eines Status Reporting sind im üblichen:

  • Zeitplan --> Soll- und Ist-Vergleich
  • Kosten --> Soll- und Ist-Vergleich
  • Ressourcen --> Kummulierte Zeiteinheiten pro Ressource
  • Probleme --> Aktuelle, das Projekt gefährdende Probleme
  • Risiko --> Identifizierte Risiken und Vorschläge zur Minimierung


Die weitere Frage, die es zu klären gilt ist, wie oft ein Status Reporting durchgeführt werden soll. Um die im Projekt eingebundenen Ressourcen nicht übermäßig mit Administrationsaufgaben zu beschäftigen, empfiehlt sich ein Status Reporting zwischen wöchentlich und monatlich. Das Erstellen von Status Reporting wird oft von den Projektmitgliedern als Überwachung und Misstrauen gewertet. Auf der anderen Seite kann es sich kein Projektleiter erlauben, eine Überraschung aufgrund mangelnden Reportings zu bekommen. Der Fokus eines Status Reporting sollte immer auf den Punkten liegen, die Probleme verursachen oder verursachen können, da der Report einen Überblick über die Gefahren in einem Projekt geben soll. Größte Aufmerksamkeit eines Status Reporting sollte jedoch auf den Soll- und Ist-Vergleichen in Bezug auf den Zeitplan, die Kosten und Ressourcen liegen.

5.4.2 Project Monitoring

Häufig leiden Projekte an Budgetüberschreitung, Terminverzug oder Ergebnisdefiziten und führen so zu Frustration im Projektteam. Projekt Monitoring dient der laufenden Überwachung der Kennzahlen in Projekten und ist anders als Status Reporting permanent abrufbar. Sie bietet primär der Finanzabteilung einen Überblick über die aktuellen Kosten in einem Projekt.

Gerade bei Unternehmen mit unterschiedlichen Projekten ist es oft schwierig den Überblick über alle Projekte, Kosten und Ressourcen zu behalten. Projekt Monitoring liefert entsprechend über verschiedene Projekte und Ressourcen Kennzahlen, die Entscheidungen vereinfachen und beschleunigen. Projekt Monitoring ermöglicht über dies auch eine Einsicht von der Projektübersicht bis hinein in einzelne Sub-Projekte und Aufgaben.

Informationen auf einen Blick:

  • Projektdetails auf einen Blick
  • Finanzielle Planung eines Projektes sowie Soll-/Ist-Vergleich
  • Planung von Ressourcen (menschliche und physische)
  • Vertragsinformationen
  • Aktueller Leistungsstand von Vertragspartnern
  • Projektstatusreport (Soll-/Ist)

5.4.3 Projektbudgetierung

Das Gesamtbudget stellt die Gesamtkosten eines Projekts dar. Das Gesamtbudget ist in Einzelbudgets aufgeteilt. Zu Projektbeginn kann es folgende Ausgangssituation geben:

1. Gesamtbudget wird fest vorgeschrieben und darf nicht verändert werden

  • Bei diesem Ansatz handelt es sich um ein Top Down-Verfahren.
  • Wird bei begrenzten Finanzmitteln eingesetzt
  • Realisierung definierter Zielbudgets

2. Gesamtbudget wird erst durch die Projektbudgetierung ermittelt

  • Dieses Verfahren wird auch Bottom-Up-Verfahren genannt.
  • Einbeziehung des Wisens und der Erfahrung von Projektbeteiligten


Nach Bernecker[28] kann die Projektbudgetierung durch folgende Merkmale dargestellt werden:

  • Detaillierte Erstellung, Kontrolle und evtl. Anpassung von Gesamt- und Einzelbudgets des Projektes.
  • Teil der Projektplanungsphase
  • Input-orientiert
  • Voraussetzungen:
    • Ziele und Anforderungen an Zeit und Qualität sind definiert
    • Projektmaßnahmen (Arbeitspakete) sind festgelegt


Nach Meredith[29] wird die Projektbudgetierung in drei aufeinanderfolgenden Schritten durchgeführt.

1. Ressourcenschätzung

Abschätzung des benötigten Ressourcenaufwands zur Erreichung des Projektziels. Für die geplanten Arbeitspakete werden die Zeitaufwände des Personaleinsatzes für die Erbringung der definierten Leistung als Manntage geschätzt. Mögliche Ressourcen für IT-Projekte:

  • Personal, Dienstleistungen
  • Betriebsmittel (Hardware, Software, Infrastruktur)
  • Büroräume
  • Dispositive Faktoren (Management)
  • Inflation, Risikoreserve

2. Kostenschätzung

Durch Bewertung der geplanten Ressourcen-Einsätze mit Kostensätzen (Stundenlohn für Entwickler) ergeben sich die Projektkosten. Einige Kosten können häufig nicht exakt genug geschätzt werden. Hierbei wird auf diverse stochastische Simulationsverfahren zurückgegriffen. Bei IT-Projekten werden laut Alby[30] hauptsächlich das Constructive-Cost-Model-Method (COCOMO) und das Function-Point-Verfahren verwendet. Nach Verzuh[31] sollte man sich an folgende Regeln („Follow the Golden Rules“) halten:

  • Direkte Einbindung in die Schätzung von Personen mit Erfahrung im Arbeitsumfeld des Projektes
  • Nutzung von Datenmaterial und Erfahrungswerten aus ähnlichen Projekten, falls verfügbar
  • Keine Verhandlung über die Kostenschätzung

3. Projektbudgetierung

Bei der Einteilung des Projektbudgets werden die in der Kostenschätzung ermittelten Kosten den zur Verfügung stehenden Finanzmitteln zugewiesen. Bei der Einteilung können sich Abweichungen ergeben, die auf folgenden Gründen basieren:

  • Je komplexer die Arbeitspakete werden, desto niedriger ist die Kostenschätzung.
    • Grund: Wenig Informationen über Details und evtl. auftauchende Probleme vorhanden.
  • Projektteams planen zu optimistisch: Unterschätzung der Kosten
  • Schwierigkeiten werden unterschätzt
  • Risikozuschläge zu hoch oder zu niedrig

Auftraggeber und Projektleitung müssen anschließend über einen Kompromiss verhandeln, wobei die Kostenschätzung selbst nicht verändert werden sollte (Goldene Regel). Möglicherweise müssen Anpassungen am Projektumfang oder Zeitplan durchgeführt werden.

5.5 Risikomanagement

http://www.projektmanagement-definitionen.de/glossar/risikomanagement/: „Effizientes Projektmanagement beinhaltet auch geeignete Massnahmen zur Risikoprävention. Ein solches Risikomanagement dient dazu, die Chancen für das Erreichen von Projektzielen zu erhöhen und die Risiken zu minimieren, die zum Scheitern eines Projekts führen können.

Projektbezogenes Risikomanagement umfasst dabei folgende Teilprozesse:

  • Zunächst muss eine Risikostrategie festgelegt werden, die darüber entscheidet, wie mit Projektrisiken umgegangen werden soll. In die Risikomanagementplanung müssen daher unter anderem Projektziele, Budget- und Zeitpläne, strukturelle Projektabläufe sowie das Verhältnis zwischen möglichen Projektchancen und -risiken miteinbezogen werden.
  • Anschliessend geht es darum, die Projektrisiken zu erkennen und zu konkretisieren (z. B. finanzielle oder personale Risiken), sowie Ursachen und erste Anzeichen von Risiken auszumachen. Diese Risikoidentifikation bildet die Grundlage für das weitere Risikomanagement.
  • Die erkannten Risiken müssen daraufhin einer umfassenden Risikoanalyse unterzogen werden, um Aussagen über den Projektausgang machen zu können. Bei der qualitativen Risikoanalyse werden die Risiken zunächst hinsichtlich ihrer Eintrittswahrscheinlichkeit und potentiellen Auswirkungen beurteilt sowie nach Prioritäten geordnet (z. B. geringes, mittleres, hohes Risiko). Mit Hilfe einer quantitativen Risikoanalyse können die qualitativen Ergebnisse anschliessend konkret beziffert werden (z. B. Schätzwerte für erwartbare Schäden).
  • Anhand dieser Daten können dann Massnahmen zur Risikobewältigung geplant und entwickelt werden (z. B. Fallback-Szenarien, alternatives Projektmanagement).

Die Überwachung und Steuerung von Risiken dient schliesslich dazu, die identifizierten Risiken während des Projekts zu beobachten, eventuell neue Risiken frühzeitig zu erkennen und rechtzeitig entsprechende Bewältigungsmassnahmen einzuleiten. Zum Risikocontrolling gehört es aber auch, das bisherige Projektmanagement im Gesamtverlauf zu bewerten und gegebenenfalls eine neue Risikostrategie zu entwickeln.“ Risikomanagement (RM) nach Madauss[32] sind „alle erforderlichen Aufgaben und Maßnahmen zur Risikobekämpfung“ und umfasst die Bereiche Risikoidentifikation, Risikoanalyse, Risikobewertung, Risikovorsorge, Risikoüberwachung und Risikosteuerung.

Gaulke: „Aus betrieblicher Sicht umfasst RM alle systematischen Maßnahmen zur rechtzeitigen Erkennung, Bewertung und Bewältigung von potentiellen Risiken. RM soll die Unternehmensführung unterstützen, wesentliche Risiken, die den Unternehmenserfolg oder- bestand gefährden können, rechtzeitig zu erkenn und zu bewältigen.

Ziel ist das frühe Erkennen von Risiken, aber auch noch nicht identifizierte Risiken sollen erkannt werden.


Grundlage des RM bilden die einzelnen Risiken


Einige Risiko Definitionen:

Madauss[33] definiert ein Risiko im Projektumfeld als die „Unwägbarkeit des technischen und/oder wirtschaftlichen Projekterfolges.“

PMI[34] sieht ein Projektrisiko als „ein unsicheres Ereignis oder eine Bedingung, dessen/deren Eintreten eine positive oder negative Auswirkung auf ein Projektziel hat“.

DIN 62198: „Kombination aus der Eintrittswahrscheinlichkeit eines bestimmten Ereignisses und seine Folgen für die Projektziele.“

Nach Gaulke[35] hat jedes Projektrisiko eine Ursache und bei Eintritt des Risikos eine Auswirkung. Die Auswirkungen beeinträchtigen die Kosten, den Zeitplan oder die Leistung/Qualität des Projektergebnisses.



Projektrisiken können nach PMI kategorisiert werden:

  • Fachlich, qualitatives, leistungsbezogenes Risiko:
    • Unrealistische Ziele
    • Verwendete Technologien sind nicht getestet und/oder zu komplex
    • Änderungen an der verwendeten Technologie während der Projektlaufzeit
  • Projektmanagementrisiken
    • Fehler bei Einsatz und Anwendung von Projektmanagement-Wissen
    • Unzureichende Planung
  • Organisatorische Risiken
    • Unzureichende Führung, Abstimmung und Priorisierung
  • Externe Risiken
    • Nicht beeinflussbar, z.B.: Gesetzesänderungen, Weltwirtschaftliche Situation, Höhere Gewalt, etc.


RM besteht aus folgenden Teilprozessen:



1. Risikoidentifikation

  • Systematische und laufende Risikoanalyse des Projektes
  • Schaffung von Frühwarnindikatoren (Kennzahlen, KPI’s) zur Kontrolle von Risikofaktoren

2. Risikoanalyse und Risikobewertung

  • Ermittlung der Eintrittswahrscheinlichkeit, Auswirkungen (Zusätzliche Kosten, Zeitverlust, Qualitätsverlust) und der Schadenshöhe
  • Berücksichtigung der gegenseitigen Abhängigkeiten der Einzelrisiken
  • Zur besseren Darstellung der Auswirkungen bei Eintritt eines Risikos können Szenariorechnungen, Sensitivitätsanalysen und Risikosimulationen durchgeführt werden

3. Risikovorsorge

  • Reduzierung der Eintrittswahrscheinlichkeit der Projektrisiken durch
    • Risikovermeidung: Ausschalten von Risikofaktoren oder Änderungen am Projekt
    • Risikoverminderung: Reduzierung von Risikofaktoren
    • Risikoabwälzung: Abgabe eines Risikos an einen anderen Risikoeigentümer
    • Risikofinanzierung: Bildung von Reserven oder Versicherungen für evtl. Eintritt des Risikos

4. Risikoüberwachung

  • Ständige Prüfung der Wirksamkeit der Risikoidentifikation, Risikoanalyse, Risikobewertung, Risikovorsorge, Risikoüberwachung

5. Risikosteuerung

  • Entscheidung über Einsatz von Maßnahmen aus der Risikovorsorge, Voraussetzung: funktionierende Risikoüberwachung
  • Verhinderung des Eintritts von Risiken und Verminderung des Schadenumfangs



PM.de: „Die Risikoüberwachung misst im laufenden Projekt die Risikoindikatoren und leitet daraus Handlungsanweisungen für die Risikosteuerung ab. Darüber hinaus soll sie neue Risiken erkennen und in den Risikomanagement-Prozess aufnehmen. Voraussetzung für effiziente Risikoüberwachung ist eine vollständige Risikoanalyse mit der Identifizierung der Projektrisiken, ihrer Faktoren und Indikatoren. Falls im Rahmen der Risikovorsorge Maßnahmen zur Reduzierung der Eintrittswahrscheinlichkeiten von Risiken ergriffen werden, so ist die Überprüfung der Wirksamkeit dieser Maßnahmen ebenfalls Aufgabe der Risikoüberwachung.“



Projekt-RM soll nicht nur während der Projektlaufzeit angewendet werden, sondern Teil eines unternehmensweiten RM-Prozesses sein.



RM bei IT-Projekten sollte ein Frühwarnsystem, basierend auf Kennzahlen und Erfahrungswerten, besitzen um die Projektleitung zeitig vor Risiken zu warnen.



RM bei IT-Projekten ist nicht als Teil des Projektcontrollings zu verstehen. Projektcontrolling läuft parallel zur gesamten Projektlaufzeit und prüft die Einhaltung der Kosten-, Zeit- und Leistungsziele. Die direkte Verantwortung für das RM bei IT-Projekten liegt beim Auftraggeber. Das Projektcontrolling wird jedoch direkt durch den Projektleiter durchgeführt

5.6 Multiprojektmanagement

Die Anzahl der Unternehmen die nur ein Projekt zur gleichen Zeit bearbeiten ist relativ gering. In der Regel gibt es mehrere Projekte die parallel ausgeführt werden. Wenn zwischen den Projekten Beziehungen bestehen, z.B. gleicher Auftraggeber, ähnliche Zielsetzungen, Verwendung der gleichen Ressourcen, Einsatzmittel so wird neben dem PM für das einzelne Projekt auch ein übergreifendes Projektmanagement benötigt, dass Multi-Projektmanagement (MPM). MPM kann als projektübergreifender Rahmen angesehen werden in dem die einzelnen Projekte effizienter geplant und gesteuert werden können. Der Begriff, früher auch als Mehrprojektmanagement bezeichnet, ist ein Oberbegriff der nach Schott und Campana[36] folgende Ziele verfolgt.

  • Projektübergreifende zentrale Organisation
  • Einheitliche Prozesse (Planung, Steuerung, etc.)
  • Standard-Werkezeuge und PM-Tools
  • Ähnliche Projektkultur
  • Höhere Wirtschaftlichkeit
  • Vermeidung von Konflikten (Leistung, Ressourcen ,Termine)
  • Schaffung von Synergieeffekten

Nach Schreckeneder[37] können noch weitere Ziele genannt werden.

  • Bewertung und Auswahl von Projektvorschlägen nach folgenden Kriterien
    • Ausrichtung des Projekts auf strategische Ziele und Leitbild des Unternehmens
    • Wirtschaftlichkeit
    • Machbarkeit
  • Erteilung von Projektgenehmigungen und Freigaben
  • Herausstellung der unterschiedlichen Bedeutung von Projekten für den Unternehmenserfolg
  • Festlegung von Prioritäten
  • Optimierung der Ressourceneinsätze
  • Abstimmung der Projektbudgets
  • Strategische Überwachung und Steuerung der Projekte
  • Entscheidung über Fortführung oder Einstellung einzelner Projekte
  • Verwaltung projektübergreifender Abhängigkeiten
  • Etablierung und Ausbau des Projekt-Wissensmanagements
  • Auswahl geeigneter Projektmanager
    Abb.8: Darstellung der unterschiedlichen Management-Methoden ©Schott, E., Campana C.: Strategisches Projektmanagement, Springer, 2005
    Abb.8: Darstellung der unterschiedlichen Management-Methoden ©Schott, E., Campana C.: Strategisches Projektmanagement, Springer, 2005


Zum MPM gehört außerdem das Programm-Management. Ein Programm ist eine Zusammenstellung mehrerer Projekte die miteinander in Beziehung stehen, ähnliche Ziele verfolgen und von einer gemeinsamen übergeordneten Instanz organisiert werden. Weiterhin gehört das Projektportfolio-Management als wichtigster Bestandteil zum MPM. Auf das Projektportfolio-Management wird im späteren Verlauf genauer eingegangen.


Das Multi-PM wird durch das Aufgabenpaket des Meta-Projektmanagements geprägt. Es enthält alle konzeptionellen, informatorischen und methodischen Aufgaben um die Planung und Steuerung der Projekt-Gesamtheit zu verbessern. Nach Rickert[38] unterscheidet man folgende fünf operative Aktivitäten in denen einzelne Projekte in das MPM eingebunden werden können.


1. Projektgenehmigung

  • Präsentation der Projektidee durch Projekt-Initiator und Freigabe durch entscheidungsbefugte leitende Angestellte
  • Bewertung und Auswahl geeigneter Projekte durch Lenkungs-Ausschuss und Projekt-Controlling

2. Projektfreigabe

  • Feinplanung des Projekts (Budget, Ressourcen, etc.) danach endgültige Freigabe
  • Prägung durch Aufgaben des Meta-Projektmanagements
  • Integration weiterer Interessengruppen und Projektbeteiligte

3. Auswahl und Zuordnung der Projektmanager

  • Festlegung der Projektmanager und damit Festlegung eindeutiger Entscheidungs- und Informationswege
  • Festlegung von Aufgaben, Kompetenzen und des Projektteams

4. Ressourcenzuordnung

  • Zuordnung der Projektmitarbeiter, Ressourcen und sonstiger Einsatzmittel zu den jeweiligen Projektmanagern
  • Zusammentreffen aller Projektbeteiligten beim Kick-Off-Meeting
  • Unter dem Einfluss des Meta-Projektmanagements wird aber auch eine Distanz zum Projektgeschehen hergestellt um es als eines unter vielen Projekt zu betrachten

5. Prioritäten, Steuerung

  • Ermittlung der verfügbaren Kapazitäten im Rahmen des Meta-Projektmanagements und Abgleich mit den zugeteilen Kapazitäten auf die einzelnen Projekte
  • Steuerung von Konflikten zwischen mehreren Projekten


Um das MPM langfristig erfolgreich zu etablieren ist die Schaffung einer projektübergreifenden Aufbau- und Ablauforganisation im Bereich der Projektorganisation empfehlenswert.


Projektübergreifende Aufbauorganisation

Institutionalisierung der operativen und strategischen Aufgaben zur Gewährleistung eines erfolgreichen Multiprojektmanagements.

1. Schaffung eines zentralen Lenkungsausschuss als die maßgebliche Instanz für das MPM

  • Auswahl, Genehmigung der Projektanträge
  • Freigabe von Projekten, Bestimmung der Projektmanager
  • Verteilung der Ressourcen und übergreifende Steuerungsmaßnahmen

2. Zentraler Projektcontroller

  • Vorlage von Entscheidungsvorschlägen für den Lenkungsausschuss mit der Fragestellung: „Machen wir die richtigen Projekte?“
  • Informationsweitergabe an Projektantragsteller
  • Wirtschaftliche Betrachtung, Planung, Kontrolle, Analyse und Steuerung der laufenden Projekte mit Hinblick auf die Fragestellung: „Machen wir die Projekte richtig?“
  • Übertragung von Erfahrungen an „neue“ Projektmanager

3. Zentraler Projektmanager-Kreis

  • Nach Möglichkeit zusammengesetzte aus allen Projektmanagern des Unternehmens
  • Ziele sind u.a.:
    • Prozess- und Projektübergreifender Informationsaustausche
    • Aufbau einer Projektkultur
    • Aus- und Weiterbildung der Projektmanager
  • Abstimmung zwischen d. Projekten
    • Organisation des Meta-Projektmanagements
  • Qualifikations-Steigerung der Projektmanager und effizientere Lösungsfindung bei Problemen des Meta-Projektmanagements


Projektübergreifende Ablauforganisation

1. Ausbildung und Entwicklung von Projekt-Fachleuten und Projektmanagern

  • Identifizierung von potentiellen Führungskräften. Analyse des beruflichen Werdegangs, Berufserfahrung. Eigenschaften und Persönlichkeitsprofil, fachliche Kompetenz
  • Pool von mehreren Personen zur Auswahl der bestmöglichen Besetzung (Personalentwicklungskonzept)
  • Besetzungsbedarf für Projektmanager-Positionen, Unternehmensziele, derzeitige Besetzungspraxis
  • Langfristiger Rahmen für Entwicklung und Einsatz des Führungskräftepotentials. Differenzierung von Einsteiger- und Entwicklungspositionen, Festlegung von Anforderungen und Vorerfahrungen und Zwischen-Positionen
  • Konkrete Pläne für einzelne Projektmitarbeiter. Festlegung eines Entwicklungsprogramms

2. Internes Vorschlagswesen für Projektideen

  • Anforderung von Projektvorschlägen
  • Klassifizierung, Sortierung, Bewertung und Auswahl geeigneter Projekte
  • Erstellung detaillierter Projektanträge und Bewurteilung nach dem Portfolio-Ansatz

3. Termin- und Kapazitätsplanung

  • Lösung von Konflikten durch Definition einer Rangfolge der Projekte und/oder einer Anpassung der Kapazitäten
  • Verfeinerung der Planung der Einzelprojekte für den Kapazitätsausgleich zwischen den konkurrierenden Projekten

4. Berichtswesen

  • Sicherstellung des Informationsflusses
  • Berichte über den Fortschritt, Leistung, Termine und Kosten der einzelnen Projekte
  • Periodische Ausführung
  • Optional: Meilenstein-, Ereignisorientierte Projektberichte

5. Projektsteuerung

  • Ermittlung der
    • Projektanforderungen aus allen Projekten
    • Verfügbare Kapazitäten der Einsatzmittel
  • Abgleich mit der Optimierung
  • Kapazitätsausgleich (z.B.: termintreu, kapazitätstreu, prioritätsgesteuert, selektiv, etc.)


Zur optimalen Übersicht ist eine Matrix mit den Projekten in den Zeilen und den Ressourcen in den Spalten nötig um im Rahmen des MPM die bestmögliche Verteilung vornehmen zu können. Hier kann PMS unterstützend eingreifen und die Projektdaten hinsichtlich der Zielstellung aufbereiten und visualisieren.


Projektportfoliomanagement

Beim Projektportfoliomanagement werden, aus der strategischen Sicht, die Projekte bewertet und ausgewählt. Nach Schott und Campana[39] ist das Projektportfoliomanagement wiederum in die beiden Prozesse Projektportfolio-Planung (Initiierung, Planung, Steuerung, Controlling) und Projektportfolio-Management (iterative und zyklische Prozesse zur Priorisierung, Entscheidung und Steuerung) unterteilt. Nach Gadatsch[40] ist IT-Portfoliomanagement in der Praxis weit verbreitet. „Nach einer Studie des Beratungshauses Bearingpoint (vormals KPMG) setzen zwei Drittel der befragten deutschen Unternehmen Portfoliomanagement zur Projektauswahl ein (vgl. Bearingpoint 2003). Mehr als 80% der antwortenden Unternehmen mit mehr als 1 Mrd. Euro Jahresumsatz sowie alle Unternehmen mit mehr als 50 IT-Projekten oberhalb 50.000 Euro-Projektbudget wenden IT-Portfoliomanagement an.“

5.7 Qualitätsmanagement

Was ist Qualität?

Die Qualität ist nach DIN 55350 Teil 11[41] wie folgt definiert: „Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse bezieht.“

Somit ist die Qualität ein definierbarer Begriff, der auch immer wieder für jedes Ziel neu beschrieben werden muss. Jede Organisation muss somit den Begriff der Qualität für sich festlegen und genau beschreiben. Diese Definition muss mit in das Projektmanagement einfließen und stellt somit die Grundlage für das Qualitätsmanagement im Zusammenhang mit Projektmanagement dar.

Das Qualitätsmanagement umfasst nach DIN EN ISO 8402[42]: „alle Tätigkeiten des Gesamtmanagements, die im Rahmen des Qualitätsmanagementsystems die Qualitätspolitik, die Ziele und Verantwortungen festlegen, sowie diese durch Mittel wie Qualitätsplanung, Qualitätslenkung, Qualitätssicherung/Qualitätsmanagement-Darlegung und Qualitätsverbesserung verwirklichen“.

Ein gutes Qualitätsmanagement hat drei Hauptziele

  • qualifizierte, gezielt eingesetzte Mitarbeiter
  • optimierte Prozesse
  • Einhaltung von Kundenwünschen

Werden diese drei Hauptziele eingehalten und in Projekt erfolgreich umgesetzt, so ist auch der Projekterfolg sicher. Es ist also erkennbar, dass das Qualitätsmanagement in direktem Zusammenhang mit dem erfolgreichen Abschluss des Projektes steht. Daher muss ein Projektmanagementsystem diese Aufgabe mit integrieren und ein Qualitätsmanagementsystem (QMS) zur Verfügung stellen bzw. ein bereits vorhandenes QMS mit einbinden.

Aufgaben eines Qualitätsmanagementsystems

Das QMS muss die Transparenz und Nachvollziehbarkeit der einzelnen Projektprozesse sicherstellen. Dazu gehört eine Auflistung der einzelnen Schritte und Schnittstellen. Diese Aufgabe übernimmt das PMS mit der Verwaltung der Subprozesse und Teilschritte. Desweiteren müssen die Schnittstellen klar definiert werden. Hierzu ist eine genaue Ressourcen- und Zeitplanung notwendig. Ist der Bedarf an Ressourcen, also die Projektmitarbeiter, Material und Zeit, genau definiert, muss eine Kontrolle der Einhaltung dieser Planung erfolgen.

Aber auch die Qualität der einzelnen Ressourcen muss sichergestellt werden. Ein Qualitätsmanagement muss den gezielten Einsatz von qualifizierten Mitarbeitern gewährleisten. Auch das zum Einsatz kommende Material muss sich einer Qualitätskontrolle unterziehen. Die Verwaltung dieser Qualitätskontrolle als Qualitätssicherung ist ebenso ein Bestandteil des QMS und zieht sich durch den kompletten Projektablauf.

Die Kosten für ein Projekt sind genauso relevant für den Erfolg des Projektes auch die Überwachung und die Einhaltung des Projektbudgets zählt mit in die Qualitätskontrolle.

Damit die Projekte mit der erwünschten Qualität beendet werden können, ist es also notwendig, dass das Qualitätsmanagement mit in das Projektmanagementsystem integriert ist und somit die Qualität über den kompletten Projektprozess überwacht wird und sichergestellt ist.

5.8 Prozessoptimierung

Die Prozessoptimierung zielt auf vorrangig auf die kürzest mögliche Projektlaufzeit. Somit ist es die Aufgabe der Software bei der Optimierung der Prozessabfolge den Anwender zu unterstützen.

Abb 9.: Ablauf der Prozessoptimierung
Abb 9.: Ablauf der Prozessoptimierung

Die kürzeste Projektlaufzeit ist anhand des kritischen Pfads definiert.

Der kritische Pfad ist nach DIN 69900-1 [43] als Weg von Projektbeginn bis Projektende definiert, an dem die Summe aller Pufferzeiten minimal ist. Die Pufferzeiten beschreiben die Leerlaufzeiten zwischen den einzelnen Vorgängen. Jeden Prozess im kritischen Weg bezeichnet man als kritischen Vorgang bzw. Prozess.

Zur Optimierung müssen die Abhängigkeiten/Beziehungen der einzelnen Vorgänge bekannt sein. Damit ist es möglich, den kritischen Weg aufzuzeigen und die Vorgänge in die optimale Reihenfolge zu bringen. Ist dies geschehen gibt der kritische Weg, ohne Veränderung der Vorgänge, die kürzeste Laufzeit des Projektes an.

Soll die Dauer des kürzesten Weges noch weiter verringert werden, so ist eine Optimierung der kritischen Vorgänge notwendig. Dies kann unter anderem durch eine Ressourcenerweiterung, wie z.B. höheren Personaleinsatz erzielt werden. Die Aufgabe der Projektmanagementsoftware ist es in einem solchen Fall, die möglichen zur Verfügung stehenden Ressourcen aufzuzeigen und evtl. freie Ressourcen automatisch dem kritischen Pfad zuzuweisen. Solch freie Ressourcen können z.B. durch Freilaufzeiten anderer Vorgänge, die sich nicht im kritischen Pfad befinden, entstehen. In Verbindung mit dem Skillmanagement, also der Übersicht über die Fähigkeiten der Mitarbeiter (siehe 4.3.2), kann es möglich sein, die freien Ressourcen gezielt dem kritischen Pfad zuzuführen.

Durch die Vermeidung von Freilaufzeiten der zur Verfügung stehenden Ressourcen findet auch eine Optimierung der Projektkosten statt. Desweiteren entsteht durch die Optimierung des kritischen Weges eine Zeitersparnis der Gesamtprojektdauer. Somit wird der Projektendtermin verkürzt, was zu einem deutlichen Wettbewerbsvorteil führen kann

5.9 Visualisierung

Die Visualisierung dient der Projektdarstellung in aufgearbeiteter und meist grafischer Form. Der Einsatz von Projektmanagementsoftware ermöglicht verschiedene Darstellungsarten, die sich im Laufe der Zeit entwickelt haben.

  • GANTT Diagramm (od. auch Balkenplan)
    Abb. 10: GANTT Diagramm
    Abb. 10: GANTT Diagramm
Das GANTT Diagramm, benannt nach dem Ingenieur Henry Gantt, der diese Darstellungsart Anfang des 20. Jahrhunderts entwickelte, stellt die zeitlichen Beziehungen der Vorgänge als horizontales Balkendiagramm dar.[44]
Jeder Einzelschritt wird als Balken mit der jeweiligen Dauer als Länge dargestellt. Jeder Vorgang wird in einer neuen Zeile dargestellt. Es können mehrere Vorgänge parallel laufen, wenn diese nicht in Abhängigkeit zueinander stehen. Somit können damit auch die Balken der einzelnen Vorgänge auf gleicher Höhe stehen. Sollten zwei aufeinanderfolgende Vorgänge nicht direkt aneinander anschließen, so entstehen Pufferzeiten. Diese Abstände werden durch eine gestrichelte Linie dargestellt. Diese werden bis zu dem Zeitpunkt eingezeichnet, an dem der darauf folgende Vorgang beginnen soll. Dieser Zeitpuffer dient als Projektzeitspielraum bei eventuell auftretenden Problemen.
Aus einem GANTT Diagramm lässt sich gut
  • die minimale Gesamtdauer des Projektes
  • die richtige Reihenfolge der Einzelschritte und
  • die Gleichzeitigkeit einzelner Schritte
ablesen


  • PERT Diagramm
    Abb. 11: PERT Diagramm mit kritischem Pfad
    Abb. 11: PERT Diagramm mit kritischem Pfad
Das Program Evaluation and Review Technique (PERT) Diagramm, ist eine weiterentwickelte Planungs- und Darstellungstechnik, welche sich durch eine höhere Informationsintegration speziell für größere und umfangreichere Projekte eignet.
Ein PERT Diagramm beschreibt die Vorgänge in Blöcken. Diese Blöcke beinhalten folgende Informationen:
  • frühester Vorgangsbeginn
  • spätester Vorgangsbeginn
  • frühestes Vorgangsende
  • spätestes Vorgangsende
  • Vorgangsdauer
  • eventuelle Pufferzeit
  • Vorgangsname


Die Verbindungen bzw. die Beziehungen zwischen den einzelnen Vorgängen werden durch Pfeile dargestellt.
Das PERT Diagramm bietet durch die Darstellungsart nicht nur die Möglichkeit die verschiedenen Beziehungen zwischen den Vorgängen darzustellen, sondern bietet auch eine gute Möglichkeit, den kritischen Pfad zu berechnen. Dieser kann durch die farbliche Kennzeichnung der Vorgangsblöcke zusätzlich gekennzeichnet werden.


  • Phasenplan
Der Phasenplan bietet ähnlich dem GANTT Diagramm eine Balkenübersicht. Allerdings bezieht sich diese Darstellungsweise nicht auf die einzelnen Vorgänge, sondern beschreibt lediglich die verschiedenen Phasen eines Projektes unter Angabe der Phasendauer als Balkenlänge.


  • Vorgangsliste [45]
    Abb. 12: Beispiel für eine Vorgangsliste mit mehreren Daten
    Abb. 12: Beispiel für eine Vorgangsliste mit mehreren Daten
Die Vorgangsliste beschreibt in tabellarischer Form die Vorgänge des Projektes. Die Liste muss folgende Daten enthalten:
  • Vorgangsbezeichnung
  • Vorgangsdauer
Desweiteren können weitere Daten wie z.B.:
  • Status
  • Anfangstermin
  • Endtermin
  • Grad der Fertigstellung
je nach Bedarf mit aufgenommen werden.


  • Projektstrukturplan
    Abb. 13: Beispiel für einen Projektstrukturplan
    Abb. 13: Beispiel für einen Projektstrukturplan
Der Projektstrukturplan besteht, wie auch das PERT Diagramm, aus Blöcken, welche die jeweiligen Projektvorgängen beschreiben. Diese sind jedoch in einer Baumhierarchie angeordnet. Die Wurzel des Baumdiagramms ist ein Block der das Gesamtprojekt beschreibt. Jede Hierarchie beschreibt einen Subvorgang der von der nächsthöheren Hierarchie abhängt. Durch diese Art der Darstellung kann ein großes und umfangreiches Projekt sehr gut in kleine Teilprojekte auf gesplittet werden. Allerdings ist keine genaue zeitliche Darstellung möglich.
  • verschiedene Berichte
Zur weiteren grafischen Auswertung gibt es diverse Berichte. Als Beispiel sind hier folgende zu nennen:
  • Kostenplan
  • Ressourcenübersicht
  • Kapazitätsplan
  • verschiedene Checklisten [46]
Um den Projektablauf zu unterstützen gibt es desweiteren diverse Checklisten. Diese können verschiedene Inhalte haben und dienen der Prozessbegleitung. Sie können zugleich als Dokumentation der Prozessbearbeitung dienen.

6 Software im Vergleich

6.1 Enterprise (proprietäre-, kommerzielle-) Software

Allgemeines
[47] Proprietäre Software ist Software, die weder frei noch halbfrei ist. Dabei muss sie nicht zwangsläufig einen kommerziellen Charakter haben. Proprietäre Software kann durch seine Entwickler kostenfrei oder kostenpflichtig angeboten werden und sollte daher nicht mit dem Begriff „Kommerzielle Software“ verwechselt werden. Die „[…] Weiterverbreitung oder Veränderung sind verboten oder verlangen von ihnen, dass sie eine Erlaubnis dafür benötigen oder sind so stark eingeschränkt, dass sie sie effektiv nicht frei verändern oder verbreiten dürfen.“ (GNU) Dies bedeutet also, dass in den meisten Fällen der Quellcode von Proprietärer Software nicht eingesehen werden kann, da dieser durch den Entwickler nicht weitergegeben wird. Wer es dennoch macht, das so genannte Reverse Engineering, benötigt vorab die Genehmigung durch die Entwickler, andernfalls macht er sich strafbar.

Abb.14: Vorteile von EPM ©it-design GmbH
Abb.14: Vorteile von EPM ©it-design GmbH


Kommerzielle Software
Kommerzielle Software wird durch Programmierer, meist Mitarbeiter von Softwareunternehmen, mit dem Ziel entwickelt, diese kommerziell zu vermarkten. Dabei muss es sich nicht unbedingt um proprietäre Software handeln. Es kann allerdings davon ausgegangen werden, dass in den meisten Fällen kommerziell entwickelte Software proprietär ist, was bedeutet, dass es „[…] auch kommerzielle freie Software, und nichtkommerzielle unfreie Software gibt.“[48]


Fehlerquellen Proprietärer Software
[49] Der traditionellen Softwareentwicklung liegt zu Beginn ein konzeptionelles Entwurfsschema vor. In diesem sollen jegliche logische bzw. angenommene Fehlerquellen ausgeschlossen werden. Die fertige Konzeption dient bei der Entwicklung als Leitfaden. Dies bedeutet, kommt es zu Fehlern bei der Konzeption, werden diese nicht selten auch in der Programmierung umgesetzt. Dies geschieht, da es in größeren Softwarehäusern gelebte Praxis ist, einen Teil des Entwicklerteams die konzeptionelle Entwicklung und einen anderen Teil die technische Umsetzung ausführen zu lassen. Die Mitarbeiter verlassen sich aufeinander, nicht auf reiner Vertrauensbasis, sondern aus Zeitgründen. Fehler die auf diesen Gründen beruhen nennt man auch 'Interne Softwarefehler'.

Abb.15: Veranschaulichung der Arbeit mithilfe EPM ©projectinstructor.com
Abb.15: Veranschaulichung der Arbeit mithilfe EPM ©projectinstructor.com

Beispiele kommerzieller Projektmanagement Software

6.2 Open Source Software

Allgemeines
Abb.16: Schaubild der Einsatzmöglichkeiten von Open Source Software
Abb.16: Schaubild der Einsatzmöglichkeiten von Open Source Software

Der Begriff Open Source kommt aus dem Englischen und bedeutet soviel wie "offene Quelle", oder "quelloffen". Gemeint ist damit der öffentlich zugängliche Quellcode der Software, die damit charakterisiert wird. Diese Art der Software steht unter einer von der Open Source Initiative (OSI) anerkannten Lizenz. Diese Organisation stützt sich bei ihrer Bewertung auf die Kriterien der Open Source Definition (OSD), die wesentlich mehr als nur die Verfügbarkeit des Quelltexts reglementiert. Sie ist fast deckungsgleich mit der Definition freier Software, fügt jedoch die Forderung hinzu, dass der Quelltext auch zur Bearbeitung und Weiterverbreitung freigegeben sein muss. Dies erwies sich als Vorteil, der auch gegenüber Kapitalgebern wirksam kommunizierbar ist. Die Philosophie von Open Source Software geht zurück auf den Grundgedanken des freien Austauschs von Wissen und Gedanken. Software kann, wie auch Ideen, jedem frei zur Verfügung gestellt werden – ohne Verluste. Wird Software weitergeben, entwickelt sie sich wie in einem evolutionären Prozess.


Kriterien
[50] Um Software als "Open Source Software" zu betiteln, bedarf es einiger Kriterien die zu erfüllen sind:

  • Lesbarkeit und Verständlichkeit des Quelltextes für den Menschen
  • Erlaubnis zum Kopieren, Verbreiten und Nutzen der Software ist gegeben
  • Erlaubnis zur Änderung und Verbreitung der Software in veränderter Form ist gegeben


Open Source = kostenlos?
In den meisten Fällen kann man diese Frage mit "Ja" beantworten, aber genau hier liegen häufig Missverständnisse in Bezug auf Open Source Software. Grundsätzlich kann die Software kostenlos aus dem Internet bezogen werden, bezahlt werden somit nur die Kosten für das Herunterladen. Möchte der Anwender neben der reinen Software aber noch Dienstleistungen wie Handbücher oder Support in Anspruch nehmen, so muss er die Zusatzleistungen bezahlen. Diese erhält er z. B. in Form einer gängigen Linux-Distribution (Zusammenstellung von Softwarepaketen), die unter anderem im Buchhandel erhältlich ist.


Einige Beispiele anderer kostenloser Vertriebsformen sind:

  • Freeware ist Software, die kostenlos genutzt werden kann. Andere Kriterien für Freeware gibt es nicht.
  • Shareware kann zunächst kostenfrei installiert und verwendet werden. Später kann der Autor für die Nutzung oder für bestimmte Formen der Nutzung Lizenzkosten verlangen. Der Autor verzichtet lediglich auf die Prüfung oder auf Maßnahmen zur Sicherstellung dieser Lizenzzahlungen. Manchmal steht Anwendern bis zur Bezahlung der Lizenzen – also bis zur Registrierung – nur ein reduzierter Funktionsumfang zur Verfügung.


Der Sicherheitsaspekt [50][51]
Abb.17: Werbekampagne für die Sicherheit eines Open Source Browsers
Abb.17: Werbekampagne für die Sicherheit eines Open Source Browsers

Bei Software, die letztlich von jedem Benutzer veränderbar ist, stellt sich jedem die Frage nach dem Sicherheitsaspekt. Im allgemeinen kann man diese Frage mit - "Ja, Open Source Software ist sicher" - beantworten. Viele Programmierer in aller Welt – man nennt sie Community oder Entwickler-Gemeinschaft – haben die Möglichkeit den Quelltext der Software anzusehen. Auf diese Art und Weise können mögliche Probleme rasch erkannt und gegebenenfalls sofort behoben werden. Aufgrund der Größe der Community ist sichergestellt, dass der Großteil der Fehler schnell gefunden und behoben wird. Da die Entwickler normalerweise namentlich bekannt sind kann man in den meisten Fällen davon ausgehen, dass Open Source Software schadfreie Software ist. Denn keiner von der Entwickler würde sich gerne nachsagen lassen, er habe schädliche Software programmiert. Des Weiteren besteht bei Open Source Software immer die Möglichkeit, Warnmeldungen ins Internet zu stellen, wenn Sicherheitslücken gefunden wurden. So existiert praktisch eine Art Frühwarnsystem, das dem Nutzer die Möglichkeit gibt sich zu informieren und damit abzusichern.
Ein weiterer Sicherheitsaspekt ist die Tatsache, dass Open Source Software bislang selten von Viren befallen wurde. Das liegt natürlich zum einen daran, dass sie noch nicht so stark verbreitet ist wie proprietäre Software, aber auch daran, dass sicheres Programmieren und Sicherheitsfunktionen im Bereich der Open Source Software traditionell einen hohen Stellenwert haben.


Beispiele für Open Source Projektmanagementsoftware
Wie in jeglichen Softwarekategorien wurde auch im Bereich der Projektmanagementsoftware eine breite Menge von Tools entwickelt. Die meisten dieser bieten eine Vielzahl von Funktionen. Welches im Einzelfall das richtige ist, hängt von den individuellen Anforderungen ab. Grundsätzlich ist aber davon auszugehen, dass die Zielgruppe der lizenzgebührenfreien Open Source Programme kleine Firmen mit schmalem Geldbeutel sind. Folgende Auswahl stellt ein aktuelles Angebot von Open Source Projektmanagementsoftware dar:

Abb.18: Screenshot des leistungsfähigen Open Source Progammes 'Open Project'
Abb.18: Screenshot des leistungsfähigen Open Source Progammes 'Open Project'

6.3 Rich Internet Application

Allgemeines[52]
Abb.19: Zusammenspiel zu einer RIA
Abb.19: Zusammenspiel zu einer RIA

Der Begriff Rich Internet Application (RIA) stammt aus dem Englischen und bedeutet "reichhaltige Internet Applikation". Traditionelle Webapplikationen wurden in der bewährten Client-Server-Architektur erstellt. Der Client (Webbrowser) schickt in diesem Modell Anfragen an den Server. Dieser liefert eine Antwort auf die Anfragen, wodurch der Client die Seite neu lädt. Dieser Prozess ist vor allem wegen der synchronen Aufrufe und dem dauernden Neuladen von Seiten langsam und für den Nutzer unkomfortabel. Durch die wachsende Popularität von Web 2.0 und der damit in Zusammenhang stehenden Ausbreitung von JavaScript und AJAX konnten Webapplikationen deutlich verbessert werden. Der Client übernimmt nun einen größeren Teil der Programmlogik. Er agiert als Mittler zwischen Browser und Server und ist verantwortlich für das Applikationsinterface und die Kommunikation zum Server. Rich Internet Applications (RIA) ähneln, was die Funktionalität und das Aussehen betrifft, immer mehr traditionellen Desktop-Applikationen.

Die ursprüngliche Entwicklerfirma von RIAs, Macromedia (inzwischen übernommen von Adobe), definiert diese auf ihrer eigenen Website wie folgt:[53]

"Rich Internet applications (RIAs) offer a rich, engaging experience that improves user satisfaction and increases productivity. Using the broad reach of the Internet, RIAs can be deployed across browsers and desktops."


Verwendete Technologien
Abb.20: Konventionelle Internet Applikationen
Abb.20: Konventionelle Internet Applikationen
Abb.21: Rich Internet Applikationen
Abb.21: Rich Internet Applikationen

Meist werden heutzutage RIAs als Flash-, AJAX- oder Silverlight-Applikationen erstellt. Folgende Technologien werden inzwischen jedoch auch verwendet:

  • Java-Applets
  • DHTML-Anwendungen
  • Java- und .NET
  • OpenLaszlo, ZK (Framework) und Adobe Flex
  • Mozilla bietet mit XUL eine XML-basierte GUI-Sprache für RIAs.
  • Das Microsoft Betriebssystem Windows Vista verwendet als Interface-Beschreibungssprache XAML, welche ebenfalls typische Bestandteile von Rich Internet Applications aufgreift.
  • Omnis Studio
  • Curl Rich Internet Application Platform
  • JavaFX Technology





Merkmale von RIAs
Abb.22: RIA im Vergleich zu anderen Web Lösungen
Abb.22: RIA im Vergleich zu anderen Web Lösungen
Folgende Merkmale verdeutlichen in knapper Form die Charakteristik von RIAs:
  • werden von einem Webdokument aus gestartet (oder ist in einem enthalten).
  • liefern dem User sofortiges Feedback, wenn dieser mit der Applikation interagiert (anstelle mehrsekündiger Pausen, während der Verarbeitung einer Anfrage von einem Server).
  • keine "Leerseiten" während der Ladezeiten wie bei herkömmlichen Webapplikationen
  • Verwendung moderner Bedienelemente, wie zum Beispiel Baumstrukturen oder Tabs
  • Möglichkeit der Nutzung von Operationen, die typisch für »Fat Clients« sind (bspw. Drag & Drop, umfassende Tastaturbedienung)
  • einfach zu entwickeln und im Besitz der universellen Reichweite von herkömmlichen Webapplikationen
  • Unabhängigkeit von plattform- oder browserabhängigem JavaScript


Beispiele für RIAs

  • Funktelefonoberflächen
  • Oberflächen für Navigationssysteme
  • Beispielrechner für Autoversicherungen
  • Navigations- und Shopoberfläche für Onlinebestellungen
  • Auto-Konfigurator im Internet
  • Oberflächen für interne ERP- oder Callcenter-Systeme


Projektmanagementsoftware als RIA?
Die RIA bringt auch Probleme mit sich: Es müssen entsprechende Plug-ins, Laufzeitumgebungen oder Skripting Engines installiert werden. Diese werden im Laufe der Zeit aktualisiert, so dass die lokale Version und die Applikationen auf dem Laufenden gehalten werden müssen.
Firmen wie Adobe, Microsoft, Google und Sun stehen im Wettbewerb, es ist momentan noch schwer vorauszusagen, welche Technologie sich durchsetzen wird. Die hohe Verbreitung von Flash und Java bietet Vorteile, Microsoft kann wiederum eine hohe Silverlight-Verbreitung via Windows Update erreichen.
Der Trend geht immer mehr in Richtung RIA, wobei die Nachfrage in den nächsten Jahren deutlich zunehmen wird. Dennoch ist davon auszugehen, dass es für größere Unternehmen nutzbare PMS nie in Form von Rich Internet Applications geben wird. Der Umfang dieser Programme ist schlichtweg zu groß und die damit in Zusammenhang strehenden Anforderungen an das System nicht zu bewältigen.

6.4 Software as a Service

Allgemeines
[54]
Abb.23: Vorr. Marktvolumen von SaaS
Abb.23: Vorr. Marktvolumen von SaaS

Software as a Service (SaaS) ist ein relativ neues, jedoch sehr schnell wachsendes und zukunftsweisendes Geschäftsmodell für Softwarehersteller. Es verfolgt die Philosophie, Software als Dienstleistung basierend auf Internettechnologien bereitzustellen, zu betreuen und zu betreiben.
Der maßgebliche Unterschied von handelsüblicher Software zu SaaS ist, dass dem Käufer mit dem Kauf der Lizenz keine Software (Out of the Box) zur Verfügung gestellt wird. Das Modell Software as a Service verfolgt vielmehr den Ansatz, dass die Software auf den Servern eines Dritten betrieben wird. Der Käufer benötigt leiglich die passende PC-Hardware für den Zugriff auf die bereitgestellte Software. Dies sind üblicherweise PCs oder Notebooks mit Internetanbindung oder respektive ein Endgerät, das Terminal-, Webbrowser- oder Java-fähig ist und keine Festplatte besitzt (Thin Clients). Der Kunde greift lediglich über ein Frontend, in der Regel einen Web-Browser, auf die Daten zu. Daher ist auch die Umschreibung "Software aus der Steckdose" geläufig.


Die Zukunft von SaaS
Laut Studien von Experton und IDC wächst der SaaS-Markt sowohl in Deutschland als auch weltweit. Gartner prognostiziert, dass bis 2012 bereits ein Drittel der Ausgaben für Unternehmenssoftware auf die „Miete“ anstatt auf den Kauf von Lizenzen entfällt.*

  • Quelle: Gartner’s Top Predictions for IT Organizations and Users, 2008 and Beyond: Going Green and Self-Healing by Yefim Natis et al. 8. Januar 2008


Vor- und Nachteile
[54]
Abb.24: Vorteile von SaaS auf einen Blick
Abb.24: Vorteile von SaaS auf einen Blick

Grundsätzlich bietet SaaS einige nicht von der Hand zu weisende Vorteile und hat aus Sicht von Fachkreisen das Potenzial, das gesamte Softwaregeschäft grundlegend zu verändern. Zum einen verspricht das Konzept wesentlich mehr Updates und damit auch eine schnellere Behebung von Bugs und Sicherheitslücken. Mit diesen Updates würden dann nicht mehr die IT-Abteilungen beim Anwender lahmgelegt, sondern sie würden für die Kunden nicht spürbar im Rechenzentrum aufgespielt. Damit bekämen die Softwarehersteller wesentlich mehr Verantwortung für den reibungslosen Betrieb der Software beim Anwender. Ihr Kontakt zum Kunden würde deutlich enger als heute, da in der Regel zwischen Hersteller und Kunde der Partner oder Dienstleister eingeschaltet ist.
Ein frappierender Nachteil von SaaS besteht in der Abhängigkeit des Endkunden ggü. dem Dienstleister während der Vertragslaufzeit. Die Tatsache, dass eine Internetverbindung zwingend notwendig ist, ist heutzutage wohl kaum mehr als allzu großer Nachteil anzuführen, da die Verbreitung von DSL-Anschlüssen, zumindest in Deutschland, stetig rapide zunimmt. Werden sensible oder unternehmenskritische Daten beim Dienstleister gelagert, ist ein besonderes Vertrauensverhältnis zwischen Dienstleister und Kunden nötig. Insbesondere bei personenbezogenen Daten sind auch die rechtlichen Aspekte mit dem Datenschutzbeauftragten zu klären. Es ist deshalb von Vorteil, zertifizierte Rechenzentren oder entsprechend vertrauenswürdige Partner zu wählen. Die versprochenen Kosteneinsparungen durch Nutzung von SaaS werden mit zunehmender Größe des Unternehmens verhältnismäßig kleiner.


Meinung des Mittelstands über SaaS
Eine Studie des Verlags IDG Business Media brachte zutage, wie der Mittelstand über 'Software as a Service' denkt. Befragt wurden 224 IT-Entscheider, die vorwiegend aus mittelständischen Betrieben mit 100 bis 1000 Beschäftigen stammen. Diese Unternehmen beschaffen ihre Software in erster Linie ganz klassisch durch den Kauf von Lizenzen (knapp 94 Prozent). Circa 40 Prozent erwerben die Programme als Free- oder Shareware, ebenso viele greifen zu Open Source Produkten. Mietsoftware verwendeten zum Befragungszeitpunkt (11/2007) gut 18 Prozent der mittelständischen Firmen. Software für Kerngeschäftsprozesse sind für den Mittelstand offenbar nicht die bevorzugten Lösungen, die sie mieten möchten. Allerdings fehlt es vielen Firmen an Erfahrung mit Software as a Service. Bei Unternehmen, die bis dato keine Mietsoftware verwenden, plant nur eine kleine Minderheit konkret einen solchen Einsatz. Weitere 15 Prozent der Befragten können sich das grundsätzlich vorstellen. Für fast 30 Prozent sind solche Angebote indes überhaupt nicht denkbar. Fast gleich groß ist der Anteil derer, für die Mietprogramme allenfalls bedingt interessant sind. Für ihre ablehnende Haltung gibt es unterschiedliche Gründe: Die einen meinen, Mietprogramme machen sie zu abhängig von dem Anbieter oder Dienstleister (rund 37 Prozent). Etwa 35 Prozent fehlt es schlicht an Erfahrung. Und etwas über 27 Prozent glauben, sie könnten SaaS-Produkte nicht oder kaum an ihre individuellen Anforderungen anpassen. Gegenüber SaaS aufgeschlossene Firmen sehen den größten Vorteil einer Mietsoftware wenig überraschend in der geringeren Eigenkapitalbindung (rund 52 Prozent) sowie den niedrigen Kosten am Anfang (gut 43 Prozent). Weniger Wartungs- und Verwaltungsaufwand führt nahezu jeder Dritte als Vorteil an. Auf die Frage, welche Applikationen sie auf keinen Fall mieten würden, entfielen mit über 38 Prozent die meisten Nennungen auf ERP-Software. Doch viele (fast 33 Prozent) haben sich hierzu offenbar noch keine Meinung gebildet. Am ehesten würden Unternehmen Office-Pakete sowie Multimedia- und Layout-Programme auf Mietbasis nutzen (knapp 54 Prozent). An zweiter Stelle (etwa 25 Prozent) folgt Netzwerk- und Telekommunikationssoftware.


Beispiele für Projektmanagementsoftware als SaaS

6.5 Vergleichsmatrix

Enterprise Software Open Source Software Rich Internet Application Software as a Service
Anschaffungskosten
  • Enterprise Lizenzkosten sehr hoch
  • keine/sehr niedrig (abhängig vom Lizenzmodell)
  • keine
  • relativ gering
Supportkosten
  • Support meist in den Anschaffungskosten enthalten
  • keine Kosten, da kein Support
  • keine Kosten, da kein Support
  • relativ gering
Hardwarebedarf
  • “neuer Stand“ notwendig, aktualisierte SW verlangt meist auch aktuellere HW
  • meist deutlich ressourcenschonender als proprietäre SW
  • geringe HW Ressourcen nötig, da benötigte Applikationen meist nicht ressourcenfressend sind
  • geringe HW Ressourcen nötig; Anforderungen des Browsers müssen erfüllt sein
Softwarequalität
  • hohe Wahrscheinlichkeit interner Bugs durch Kommerzialität; hohe Updatedichte
  • durch viele Programmierer ist die Fehleranfälligkeit am geringsten
  • durch viele/schnelle Updates schnelle Behebung von Bugs und Sicherheitslücken
  • durch viele/schnelle Updates schnelle Behebung von Bugs und Sicherheitslücken
Merkmale (USPs)
  • Leistungsumfang sehr hoch
  • Produkte können von kleinst- bis hin zum MultiProjekt alles verwalten
  • sehr guter Support
  • je nach Lizenz ist die Software im Vergleich sehr günstig/kostenfrei
  • "große Produkte" bieten nahezu einen ähnlichen Umfang wie kommerzielle Produkte
  • durch die Vielzahl der Programmierer wenige Bugs anzunehmen; schnelle Behebung
  • geringe Hardwareanforderungen machen die Nutzung auf nahezu allen Internetrechnern möglich
  • Bugs können/werden unbemerkt serverseitig per Updates behoben werden
  • relativ geringe Anschaffungs-(Miet-)kosten
  • Bugs können/werden unbemerkt serverseitig per Updates behoben werden
  • guter Support anzunehmen
  • geringe Hardwareanforderungen nötig
  • keine eigene Datenbelastung
Datensicherheit
  • hohe Datensicherheit, da diese (anzunehmen) auf den eigenen Servern liegen
  • hohe Datensicherheit, da diese (anzunehmen) auf den eigenen Servern liegen
  • Daten liegen auf lokalem Dateisystem, für die Sicherheit ist ausschließlich der Anwender zuständig
  • Daten liegen auf Servern eines Drittanbieters, daher: hohes Vertrauen demjenigen ggü. nötig
Tabelle 3: Vergleichsmatrix

7 Schlussbetrachtung

Viele Unternehmen stehen aufgrund starken Wettbewerbsdruck vor der Notwendigkeit, sowohl Ihre Geschäftsprozesse als auch Projekte auf optimale Weise zu organisieren. Projektmanagement hat seit der Jahrtausendwende einen grossen Sprung nach vorne gemacht und auch der Markt für PMS ist in den letzten Jahren stark gewachsen. Die Anzahl verfügbarer Produkte ist sehr gross und stetig wachsend. Es gibt PMS in allen Varianten und Spezialisierungen für alle Bereiche und Vorgehensmodelle. Einige Tools eignen sich eher zur Planung, Steuerung, Kontrolle und Verfolgung von Einzelprojekten. Es exisitieren aber auch umfangreiche Projektmanagement-Suites, die zur Administration und Kontrolle mehrerer (paralleler) Projekte geeignet sind. Nachteilig wirkt sich oft eine fehlende Integration in anderen ERP- und IT-Systeme des Kunden aus. Ebenso fehlt häufig eine Anpassung an branchenspezifische Rahmenbedingungen und Geschäftsprozesse. Damit PMS zielführend eingesetzt werden kann sollte der Benutzer sich über seine Anforderungen und Rahmenbedingungen im Klaren sein. Im besten Fall deckt ein PMS natürlich das Aufgabenspektrum komplett ab, aber sollte darauf geachtet werden, dass die Software leicht bedienbar ist und stabile Schnittstellen zu anderen IT-Systeme bietet. In grösseren Unternehmen hat sich PMS schon seit einigen Jahren etabliert und mittlerweile haben auch die kleinen und mittleren Unternehmen (KMU) die Chancen erkannt, welche sich durch Nutzung von PMS ergeben.

8 Tabellenverzeichnis

Tab.-Nr.Tabelle
1Aufgaben mit Projektcharakter
2Formen der Projektorganisation
3Vergleichsmatrix

9 Abbildungsverzeichnis

Abb.-Nr.Abbildung
1Aufgaben in Wirtschaftsunternehmen
2Reine Projektorganisation
3Projektkoordination (Stab-Projekt-Organisation)
4Matrix-Projektorganisation
5Aufgaben des Projektmanagements
6Der PM-Regelkreis
7Aufgaben in Wirtschaftsunternehmen
8Darstellung der unterschiedlichen Management-Methoden
9Ablauf der Prozessoptimierung
10GANTT Diagramm
11PERT Diagramm mit kritischem Pfad
12Beispiel für eine Vorgangsliste mit mehreren Daten
13Beispiel für einen Projektstrukturplan
14Vorteile von EPM
15Veranschaulichung der Arbeit mithilfe EPM
16Schaubild der Einsatzmöglichkeiten von Open Source Software
17Werbekampagne für die Sicherheit eines Open Source Browsers
18Screenshot des leistungsfähigen Open Source Progammes 'Open Project'
19Zusammenspiel zu einer RIA
20Konventionelle Internet Applikationen
21Rich Internet Applikationen
22RIA im Vergleich zu anderen Web Lösungen
23Vorr. Marktvolumen von SaaS
24Vorteile von SaaS auf einen Blick

10 Abkürzungsverzeichnis

AbkürzungBedeutung
ANSIAmerican National Standards Institute
CMMICapability Maturity Model Integration – Vereinigung mehrere Reifegradmodelle zur Bewertung von Unternehmensprozessen
DINDeutsches Institut für Normung e.V.
DVDatenverarbeitung
EDVElektronische Datenverarbeitung
GLGruppenleiter
GNUGNU is Not Unix - Projekt, welches das Ziel hat ein vollständig freies Betriebssystem zu entwickeln
IEEEInstitute of Electrical and Electronics Engineers
ITInformationstechnologie
MAMitarbeiter
OSDOpen Source Definition
OSIOpen Source Initiative
PLProjektleiter
PMProjektmanagement
PMBOK Project Management Body of Knowledge
PMFProjektmanagement-Fachmann
QMQualitätsmanagement
RIARich Internet Application
SaaSSoftware as a Service
SMSkillmanagement
TMTeammitglied

11 Fußnoten

  1. ↑ Vgl. Deutsche Gesellschaft für Projektmanagement e.V. (2001), S.27
  2. ↑ Vgl. Kraus, G., Westermann, R. (1995) S.15
  3. ↑ Vgl. Kraus, G., Westermann, R. (1995) S.11
  4. ↑ Vgl. Schelle (2001)
  5. ↑ Vgl. Projektmagazin.de (2008)
  6. ↑ Vgl. Schelle (2001)
  7. ↑ Vgl. PMF (1999)
  8. ↑ Vgl. Heeg (1999) Seite 79
  9. ↑ Vgl. Jenny B. (2001)
  10. ↑ 10,0 10,1 Vgl. Burghardt (2008)
  11. ↑ Vgl. Burghardt (2002)
  12. ↑ Vgl. Projektmagazin.de (2008)
  13. ↑ Vgl. Kraus, G., Westermann, R. (1995) S.11
  14. ↑ Vgl. Landau (2004) Seite 166 ff.
  15. ↑ Vgl. DIN 10007
  16. ↑ Vgl. Alpar (2008)
  17. ↑ 17,0 17,1 Vgl. Versteegen
  18. ↑ Vgl. Erdmann, 2008
  19. ↑ Vgl. Schuerholz, 2001
  20. ↑ Vgl. Block, 2008
  21. ↑ Vgl. Herrhausen, ohne Jahr
  22. ↑ Vgl. Beiderwieden (2001)
  23. ↑ Vgl. Jenny (2001)
  24. ↑ Vgl. Becker (2008)
  25. ↑ Vgl. Landau / Hellwig (2004) S. 170
  26. ↑ Vgl. Beiderwieden (2001)
  27. ↑ Vgl. Projectperfect (2009)
  28. ↑ Vgl. Bernecker (2003)
  29. ↑ Vgl. Meredith (2003)
  30. ↑ Vgl. Alby (2008)
  31. ↑ Vgl. Verzuh 2005
  32. ↑ Vgl. Madauss (2000)
  33. ↑ Vgl. Madauss 2000
  34. ↑ Vgl. PMBOK (2003)
  35. ↑ Vgl. Gaulke (2004)
  36. ↑ Vgl. Schott, Campana (2005)
  37. ↑ Vgl. Schreckeneder (2005)
  38. ↑ Vgl. Rickert (1995)
  39. ↑ Vgl. Schott, Campana (2005)
  40. ↑ Vgl. Gadatsch (2006)
  41. ↑ Vgl. DIN 55350
  42. ↑ Vgl. DIN EN ISO 8402
  43. ↑ Vgl. DIN 69900-1
  44. ↑ Vgl. Kerber-Kunow
  45. ↑ Vgl. Projektmagazin.de, 2, (2008)
  46. ↑ Vgl. Projektmagazin.de, 3, (2008)
  47. ↑ Vgl. Projektmagazin, 4, (2008)
  48. ↑ Vgl. GNU (2001)
  49. ↑ Vgl. fh-brandenburg (2005)
  50. ↑ 50,0 50,1 Vgl. Debianhandbuch (1999-2008)
  51. ↑ Vgl. Bundesamt für Sicherheit in der IT (2009)
  52. ↑ Vgl. Praegnanz (2007)
  53. ↑ Vgl. Adobe.com (2008)
  54. ↑ 54,0 54,1 Vgl. IBM.com (2008)

12 Literaturverzeichnis

Adobe.com (2008) Rich Internet Applications, online im Internet unter URL:http://www.adobe.com/resources/business/rich_internet_apps/#closed, Version August 2008, Abruf 10.11.2008
Alby (2008) Alby, T.: Projektmanagement-Definitionen Kostenschätzung, online im Internet unter URL: http://www.projektmanagement-definitionen.de/glossar/kostenschaetzung, Stand: 08.01.2008
Alpar (2008) Alpar (2008): Autor(en): Alpar, Paul / Grob, Heinz Lothar / Weimann, Peter / Winter, Robert: Anwendungsorientierte Wirtschaftsinformatik - Strategische Planung, Entwicklung und Nutzung von Informations- und Kommunikationssystemen, Seite 346, 5., überarb. u. akt. Aufl. 2008
Babich (1986) Babich, W. A.: Software Configuration Management, Cooridnation for Team Productivity,Addison-Wesley Publishing Company, 1986
PMF (1999) Bech, K., Wolff, U. (Hrsg.): Projektmanagement-Fachmann, Band 1 und 2, 5.Auflage,RKW-Verlag, 1999
Becker, H. (2008) Becker, H.: Investition und Finanzierung: Grundlagen der betrieblichen Finanzwirtschaft, Veröffentlicht von Springer, 2008
Becker, M. (2002) Becker, M.: EDV-Wissen für Anwender, 12. Auflage, Verlag Industrielle Organisation, Zürich, 2002
Beiderwieden (2001) Beiderwieden, A.: Projektmanagement für IT-Berufe, Veröffentlicht von Bildungsverl. Eins, Stam, 2001
Block (2008) Block, A.: Personaleinsatz in internationelen Unternehmen, Grin Verlag, München, 2008
Beiderwieden (2001) Bernecker, M.: Handbuch Projektmanagement, Veröffentlicht von Oldenbourg Wissenschaftsverlag, 2003
Bundesamt für Sicherheit in der IT (2009) Fragen und Antworten zu Open Source, online im Internet unter URL:http://www.bsi-fuer-buerger.de/opensource/11_02.htm, Abruf 08.01.2009
Burghardt (2008) Burghardt, M.: Projektmanagement: Leitfaden für die Planung, Überwachung und Steuerung von Projekten, 8. Auflage, Siemens, München 2008
Corsten (2004) Corsten, H.: Projektmanagement. Lehr- und Handbücher der Betriebswirtschaftslehre, München, Wien, Oldenbourg, 2000
Debianhandbuch (1999-2008) Freie Software / Open Source, online im Internet unter URL:http://debiananwenderhandbuch.de/freiesoftware.html, Version 1999-2008, Abruf 06.01.2009
Deutsche Gesellschaft für Projektmanagement e.V. (2001) Deutsche Gesellschaft für Projektmanagement e.V.: Projektmanagement Fachmann, 6. Aufl., Eschborn 2001
DIN EN ISO 8402 (1994) DIN EN ISO 8402: Qualitätsmanagement und Qualitätssicherung - Begriffe (EN ISO 8402:1994), Berlin, Beuth Verlag, 1994
DIN EN ISO 10007 (1996) DIN EN ISO 10007: 1996 Qualitätsmanagement - Leitfaden für Konfigurationsmanagement (ISO10007:1995) Dreisprachige Fassung EN ISO 10007:1996. Berlin: Beuth Verlag, 1996
DIN 69901 (1987) DIN 55350:2008: Begriffe zum Qualitätsmanagement, Berlin, Beuth Verlag, 2008
DIN 69901 (1987) DIN 69000-1:1987: Projektwirtschaft - Netzplantechnik - Begriffe, Berlin, Beuth Verlag, 1987
DIN 69901 (1987) DIN 69901: Projektwirtschaft, Projektmanagement, Begriffe. Berlin, Wien, Zürich: Beuth-Verlag, 1987
Erdmann (2008) Erdmann, W.: Skills managen ist nicht trivial, 2008, online im Internet unter URL: http://www.waldemar-erdmann.de/category/skillmanagement/diplomarbeit-skillmanagement
fh-brandenburg (2005) Proprietäre- vs. Freie Software, online im Internet unter URL: http://zeus.fh-brandenburg.de/~muehlber/lehre/sichman/essays/finals/ps_vs_oss.pdf, Version 01.2005, Abruf 15.10.2008
Gadatsch (1987) Gadatsch, A. / Mayer, E.: Masterkurs IT-controlling Grundlagen und Praxis, Veröffentlicht von Vieweg+Teubner Verlag, 2006
Gaulke (2004) Gaulke, M.: Risikomanagement in IT-Projekten, Veröffentlicht von Oldenbourg Wissenschaftsverlag, 2004
Girmendonk (2005) Girmendonk, M.: Optimierung von Arbeitsprozessen im Projektmanagement durch unterstützende Software am Beispiel von Microsoft Project, online im Internet unter URL: http://www.girmendonk-media.de/Neue_Dateien/Facharbeit.pdf, Stand: 06.01.2009
GNU (2001) Kategorien freier und unfreier Software , online im Internet unter URL: http://www.gnu.org/philosophy/categories.de.html, Stand: 29.07.2001, Abruf: 12.12.2008
GPM-Magazin (2005) GPM-Magazin: PMaktuell - Heft 4/2005, PM-Software-Studie: Softwareunterstützung für Projektmanagement-Aufgaben, online im Internet unter URL: http://www.pm-software.info/data/dokumente/806f2ae222a315bb4/StandTrend.pdf, Stand: 06.01.2009
Heeg, F.J. (1993) Heeg, F.J.: Projektmanagement: Grundlagen der Planung und Steuerung von betrieblichen Problemlöseprozessen, REFA, Verband für Arbeitsstudien und Betriebsorganisation e.V., 2.Auflage, München, Wien: Hanser, 1993
IBM.com (2008) Software as a Service, online im Internet unter URL: http://www-935.ibm.com/services/de/index.wss/offering/ebhs/a1023425, Version Januar 2008, Abruf 15.01.2009
IPMI (2008) Institut für Projektmanagement und Innovation, Unabhängige Plattform zum Thema Projektmanagement-Software: Produktliste, online im Internet unter URL: http://www.pm-software.info/produktliste.html, Stand 07.01.2008
ISPRI (2009) ISPRI - Forschungszentrum für Informationssysteme in Projekt-und Innovationsnetzwerken: Marktstudie PM-Software, online im Internet unter URL: http://www.ispri.de/vendors.php?id=12&isChild=1, Stand 07.01.2009
Jenny (2001) Jenny, B.: Projektmanagement in der Wirtschaftsinformatik, 5.Auflage, Zürich:vdf Hochschulverlag AG an der ETH Zürich, 2001
Jenny (2005) Jenny, B.: Projektmanagement - Das Wissen für eine erfolgreiche Karriere, Veröffentlicht von vdf Hochschulverlag AG, 2005
Kessler (2004) Kerber-Kunow, A.: Projektmanagement und Coaching, http://www.uwe-kern.de/winfwiki/index.php?title=IT-Projektmanagement_-Software_im_Vergleich&action=edit&section=34Hüthig Verlag, Heidelberg, 2000
Kessler (2004) Kessler, H., Winkelhofer G.: Projektmanagement: Leitfaden zur Steuerung und Führung von Projekten, 4. Auflage, Springer, Berlin 2004
Klammbauer (2007) Klambauer, T.: Comparison of Projectmanagement-Software, http://www.klambauer.info/pms.pdf, Linz 2007
Kolisch / Harland (2008) Kolisch, R. / Harland, P. E.: Projektmanagement - Projektbudgetierung, online im Internet unter URL: http://www.innovationsmanagement.de/projektmanagement/projektbudgetierung.html, Stand: 08.01.2008
Kraus/Westermann (1995) Kraus, G./Westermann, R.: Projektmanagement mit System, 3. Aufl., Wiesbaden 1995.
Kunz (2007) Kunz, C.: Strategisches Projektmanagement, Springer, 2007
Landau / Hellwig (2004) Landau, K., Hellwig R.: Projektmanagement. Grundlagen und Anwendungen, Ergonomia Verlag; Auflage: 1., Stuttgart, 2004
Madauss (2000) Madauss, B. J.: Handbuch Projektmanagement, Schäffer-Poeschel Verlag, 6. Auflage, Stuttgart 2000
Meredith / Mantel (2003) Meredith, J. R. / Mantel, Samuel J.: Project Management - A Managerial Approach, 5. Auflage, New York, 2003
PMBOK (2003) Project Management Institute (Hrsg.): A guide to the Project Management Body of Knowledge (PMBOK Guide), Ausgabe 2000, deutsche Übersetzung, Newtown Square, Pennsylvania, USA: PMI, 2003
Praegnanz (2007) Rich Internet Applications, online im Internet unter URL: http://praegnanz.de/weblog/rich-internet-applications, Version April 2007, Abruf 01.12.2008
Projektmagazin.de (2008) Projekt Magazin, PM-Software Marktplatz, online im Internet unter URL: http://www.projektmagazin.de/marktplatz/projektmanagementsoftware.html, Stand 07.01.2009
Projektmagazin.de, 2, (2008) Projekt Magazin, Vorgangsliste, online im Internet unter URL: http://www.projektmagazin.de/glossar/gl-0892.html, Stand 01.2009
Projektmagazin.de, 3, (2008) Projekt Magazin, Checkliste, online im Internet unter URL: http://www.projektmagazin.de/glossar/gl-0191.html, Stand 01.2009
Projektmagazin.de, 4, (2008) Projekt Magazin, Mehrplatz, online im Internet unter URL: http://www.projectperfect.com.au/info_status_report.php, Stand 01.2009
Projectperfect (2009) Project Status Reporting, online im Internet unter URL: http://www.projectperfect.com.au/info_status_report.php, Stand 11.2008
Rickert (1995) Rickert, D.: Multiprojektmanagement in der industriellen Forschung und Entwicklung. Gabler Verlag, Wiesbaden, 1995
Ruf / Fittkau (2007) Ruf, W. / Fittkau, T.: Ganzheitliches IT-projektmanagement: Wissen- Praxis- Anwendungen, Veröffentlicht von Oldenbourg Wissenschaftsverlag, 2007
Schelle (2001) Schelle, H. (2001): Projekte zum Erfolg führen. Projektmanagement systematisch und kompakt. 3. Auflage. München: dtv-Verlag, 2001
Schott, Campana (2005) Schott, E., Campana C.: Strategisches Projektmanagement, Springer, 2005
Schreckeneder (2005) Schreckeneder, B. C.: Projektcontrolling: Projekte überwachen, Steuern, präsentieren. Edition: 2, Haufe Verlag DE, 2005
Schuerholz (2001) Schuerholz, D.: Diplomarbeit: Skill-Management zur Unterstützung des dispositiven Aufgaben des Personalwesens - Konzeptvorschlag für einen ganzheitlichen Software-Ansatz auf Basis einer Anforderungsanalyse und einer empirischen Studie, 2001
Versteegen (2003) Versteegen, G.: Konfigurationsmanagement, Berlin, Heidelberg, Springer, 2003
Verzuh (2005) Verzuh, E.: The Fast Forward MBA in Project Management: quick tips, speedy solutions, cutting-edge ideas, Veröffentlicht von John Wiley and Sons, 2005
Von „http://winfwiki.wi-fom.de/index.php/IT-Projektmanagement_-Software_im_Vergleich“
Persönliche Werkzeuge