Was sind IS-Projekte?

In größeren IT-Organisationen ist die Arbeit in Projekten inzwischen gang und gäbe. Oft wird dabei von Softwareprojekten oder von Softwareentwicklungsprojekten gesprochen. Diese Begriffe führen zur Vorstellung, dass im Rahmen solcher Projekte „nur“ Software entwickelt wird. Dies greift jedoch zu kurz: Software entfaltet ihre Wirkung erst im Zusammenspiel mit der Umgebung, in der sie eingesetzt wird. Zu jedem Projekt einer IT-Organisation gehört deshalb auch die Betrachtung der Geschäftsprozesse, der Organisation und der Sachmittel, weshalb es besser ist, in diesem Rahmen von Systementwicklungsprojekten oder generell von IT-Projekten zu sprechen.

Bevor wir uns mit dem Ablauf von Projekten beschäftigen ist zunächst eine Abklärung des Projektbegriffs selbst erforderlich. Oft wird von Projekten gesprochen, die keine wirklichen Projekte sind – andererseits geben bereits die Beschreibungen des Projektbegriffs einige Hinweise darauf, warum Projekte keine normalen Aufgaben und Routinetätigkeiten darstellen.

Ein Projekt zeichnet aus, dass es eine einmalige Aufgabe mit besonderen Merkmalen ist:

• Es ist zielorientiert bezüglich Leistung, Ressourcen, Kosten und Zeitrahmen
• Es ist zeitlich begrenzt – Anfang und das (geplante) Ende sind definiert
• Es ist komplex und dynamisch – es sind stark vernetzte Teilaufgaben zu koordinieren, es gibt viele Einflussfaktoren und es ist mit Veränderungen während der Projektlaufzeit zu rechnen
• Projekte sind interdisziplinär und abteilungsübergreifend – es sind unterschiedliche interne und externe Fachbereiche und Organisationseinheiten daran beteiligt
• Und vor allem: es ist neuartig und damit riskant und nur begrenzt abschätzbar

Während der Dauer des Projekts bildet das Projekt selbst ein eigenes Unternehmen auf Zeit. Es gibt Verantwortlichkeiten für Produkte und Ergebnisse, die dem Projekt zugeordneten Mitarbeiter müssen geführt werden, Marketing ist zu betreiben usw.

Projektmanagement als Steuerung eines Projekts ist das Management eines meist komplexen, sozialen Gefüges und der entsprechenden Kooperationen zwischen allen Beteiligten und Betroffenen (den Stakeholdern). Diese Gestaltung der Kooperation ist ein wesentlicher Beitrag zur Erreichung der Projektziele, woraus auch projektspezifische Verhaltensweisen, Werte und Identitäten dieses „Unternehmens“ resultieren.

Projekte und damit verbundenes Projektmanagement werden nicht zum Selbstzweck betrieben, sondern um einen Nutzen zu erzeugen. Gleichzeitig ist Projektmanagement durch den Einsatz von Personen und Mitteln auch mit Kosten verbunden.

Systematisches Projektmanagement führt zu erfolgreicheren Projekten, ohne dass dies mit ständigen heroischen Anstrengungen der Mitarbeiter erkauft werden muss. Gleichzeitig wird der Projekterfolg personenunabhängiger und berechenbarer. Durch konzentriertes und planvolles Vorgehen ergeben sich kürzere Bearbeitungszeiten und damit geringere Gesamtkosten.

Nach (Burghardt, 1999) sinkt der prozentuale Kostenanteil für Projektmanagement mit der Größe der Projektkosten und liegt z.B. bei einem Projektkostenvolumen von 100 Mio. EUR bei weniger als 2 %. Bei kleineren Projekten (um 50.000 EUR) ist dagegen ein steiler Anstieg zu verzeichnen, da von einer gewissen Grundlast ausgegangen werden muss – es wird mit etwa 8 % Kostenanteil gerechnet. 

Warum dann also bei so vielen Kosten ein systematisches Projektmanagement? 

Weil: „Projektmanagement kostet etwas, kein Projektmanagement kostet mehr“! Planung und Kontrolle – die Haupttätigkeiten des Projektmanagers – und der Einsatz von entsprechenden Instrumenten sind eine notwendige, wenn auch alleine nicht hinreichende Bedingung für den Projekterfolg. 

Anders ausgedrückt: Ein organisierter Projektablauf ist dem Projekterfolg förderlicher als ein unorganisierter. 

Gleichzeitig ist das auch der Grund, warum nicht jede Aufgabe als Projekt abgewickelt werden soll: Die mit einem professionellen Projektmanagement verbundenen Kosten müssen auch gerechtfertigt sein.

Warum ist Planung notwendig in der Softwareentwicklung?

Jegliches Vorhaben, das einen Zeithorizont von wenigen Wochen übersteigt, bedarf einer gewissen Planung. Dies gilt ebenso für alle Projekte rund um Informationssysteme – sei es eine Neubeschaffung, eine Erweiterung eines bestehenden Systems, eine Umstellung eines vorhandenen Systems oder ein Versionswechsel.

„Planung ist zwar nicht möglich, aber notwendig“.

Dieses von (Weltz, 1996) formulierte Paradoxon gibt einen Einblick in die Welt der Planung. Planung ist – ebenso wie beispielsweise die Risikoanalyse – eine Schätzung und ein Blick in die Zukunft. Allerdings: Ohne jeglichen Plan ist es genauso wie eine Reise ohne Ziele – irgendwo wird man schon irgendwann ankommen.

Nun sind Planungsvorgänge in der Realität durchaus möglich. Nehmen wir als Beispiel einen Kostenplan: Zu Projektbeginn liegen meistens schon genügend Informationen vor, dass eine erste Kostenplanung durchgeführt werden kann. Der Projektmanager kann eine erste Schätzung vornehmen, zu welchem Zeitpunkt im Projekt welches Material gekauft und bezahlt werden muss oder zu welchem Zeitpunkt Teilleistungen geliefert, verrechnet bzw. bezahlt werden können oder müssen.

Ähnlich verhält es sich mit einem Zeitplan. Eine erste Projektorganisation steht und damit ist bekannt, wieviele Personen die nächste Zeit im Projekt verbringen werden. Ein geplanter Endtermin für das Projekt ist bekannt, es gibt (z.B. aus der Angebotskalkulation oder aus einer Vorstudie) Informationen, wieviel Zeit für welche Teilleistung vorgesehen ist und dergleichen mehr.

Projekte werden meist unter Zeitdruck durchgeführt. Daher hat häufig die rasche Erfüllung von Teilleistungen und nicht die Projektdefinition und die Projektplanung Priorität. Wird die Projektstartphase – die durchaus 15…30% der gesamten Projektlaufzeit in Anspruch nehmen kann! – vernachlässigt, so hat dies weitreichende Konsequenzen für das gesamte Projekt – meist in Form von Zeit- und Kostenüberschreitung und den damit verbundenen Auswirkungen.

Eine nicht ordentlich aufgesetzte Projektstartphase führt zu

• Unrealistischen und unklaren Projektzielen
• Keiner ganzheitlichen Problemsicht bei den Projektmitarbeitern
• Keine einheitliche Identifikation mit dem Projekt
• Zuwenig Sensibilität für das Umfeld
• Zuwenig Verbindlichkeit bezüglich der Projektziele bei den Projektmitgliedern
• Unklaren Rollenerwartungen

und dergleichen mehr. 

Zur Fragestellung „Warum scheitern Projekte?“ gibt es etliche Studien – stellvertretend soll dafür jene der  (GPM und PA Consulting Group, 2008) stehen:

Ziele der Projektstartphase müssen daher sein:

• Erreichen einer ganzheitlichen Problemsicht
• Volle Konzentration auf das Projekt zu Projektbeginn
• Entwicklung einer gemeinsamen Sprache der Projektmitglieder, eines Wir-Gefühls und eines konstruktiven Arbeitsklimas
• Schaffung von Verbindlichkeit bezüglich der Projektziele
• Entwicklung von Projektplänen bezüglich Leistungen, Qualität, Terminen, Ressourcen und Kosten
• Aufbau einer entsprechenden Projektorganisation mit Festlegung der Aufgaben und Kompetenzen sowie
• Sicherung der Unterstützung für das Projekt durch das Top-Management

Geplant werden daher zumindest

• Termine
• Kosten
• Arbeitspakete und Lieferungen
• Kapazitäten und Ressourcen
• Risiken und Chancen
• Umgang mit Stakeholdern
• Qualität
• Zahlungen

Begleitet wird eine Projektumsetzung u.a. durch ein angemessenes Controlling, welches innerhalb eines Projekts laufend Plan-/Ist-Vergleiche durchführt und damit durch die Rückkoppelung ein wichtiges Steuerinstrument für einen Projektverlauf darstellt.

Was ist die „Make or Buy“-Frage in der Softwareentwicklung?

Grundsätzlich stellt sich vor einem Projekt die Frage, ob das Projekt überhaupt notwendig und sinnvoll ist, also wird die Software wirklich gebraucht und ist die Annahme realistisch, dass sie sich in der geplanten Zeit amortisiert? Hier unterstützen die Ansätze aus der Business Analyse, nämlich eine Lösung auszuwählen, welche auch einen entsprechenden Nutzen bringt.

Ist dies der Fall, muss geklärt werden, ob die Software entwickelt werden muss. Möglicherweise kann man sie auch kaufen oder mit erträglichem Aufwand aus einer vorhandenen Software ableiten. Diese Frage wird durch das Schlagwort „Make or Buy“ bezeichnet. Tatsächlich ist die Alternative zum Entwickeln (Make) nicht nur der Kauf (Buy), sondern auch die Anpassung oder Wiederverwendung bestehender Software. 

Dass die Entwickler stets lieber entwickeln, ist klar, diese sollte aber die Entscheidung nicht vorgeben. Die Kosten einer Neuentwicklung werden in der Regel grob unterschätzt, und zwar umso stärker, je mehr neu entwickelt wird. Die Kosten einer Entwicklung steigen meist während der gesamten Entwicklungsdauer. 

Größere Flexibilität spricht für die Eigenentwicklung oder für die Vergabe eines entsprechenden Auftrags einer Individualentwicklung. Allerdings ist es meist unwirtschaftlich, eine perfekte Lösung anzustreben; eine einfachere Lösung ist oft der bessere Kompromiss.

Im Gegensatz dazu steigt die Planungssicherheit, wenn mehr fertige Komponenten eingesetzt werden. Der Kauf wird unter Umständen billiger als ursprünglich erwartet, weil die Preise der Software fallen oder ihr Funktionsumfang wächst. Durch Kauf erhält man rasch eine relativ ausgereifte Software, in die höherer Entwicklungsaufwand geflossen ist, als ein einzelner Kunde zahlen könnte. Der Aufwand für Wartung und Portierungen ist viel geringer. 

Als Faustregel kann angenommen werden: Kauf oder Wiederverwendung ist dann vorteilhaft, wenn es sich nicht um Software handelt, die das zentrale Know-How des Unternehmens enthält. Es darf jedoch nicht übersehen werden, dass auch bei Kauf zumindest eine Spezifikation und ein Test etc. notwendig sind (siehe auch 3.2 Modellierung von Informationssystemen – Lasten- und Pflichtenheft).

Ist diese Entscheidung getroffen, geht es an die Auswahl – sei es die Auswahl einer bestehenden, zukaufbaren Software, die Auswahl eines Lieferanten für eine zu entwickelnde Software oder die Auswahl einer internen Abteilung.

Grundlage für jegliche Auswahl ist ein Lastenheft (siehe 3.2 Modellierung von Informationssystemen – Lasten- und Pflichtenheft). In einem korrekten Lastenheft sind alle Anforderungen und Randbedingungen an das durchzuführende Projekt aufgeführt. Dies ermöglicht es nun, an (interne und externe) Lieferanten heranzutreten und hierfür Angebote einzuholen.

Die Auswahl eines Lieferanten ist durch verschiedene Faktoren bestimmt und kann nach verschiedenen Kriterien durchgeführt werden. Faktoren können sein

• Fachwissen und Expertise: Know-how Transfer – muss das Wissen des Anbieters auf das eigene Unternehmen übertragen werden?
• Lizenz- und Preismodell: Beurteilung der Kostennutzen-Relation
• Produktreputation und Marktposition: Größe des Unternehmens, Marktanteil, Roadmap für Weiterentwicklung und Referenzen
• Geschäftsbeziehungen: Vorübergehend oder dauerhaft, wie kann man zu einem anderen Anbieter wechseln (rechtlich, technisch), wer hat die Verantwortung für Informationssicherheit etc.
• Erfahrung und Ruf des Anbieters: Hinweis auf Fähigkeit, vertraglichen Verpflichtungen nachzukommen
• Stabilität des Anbieters: Zukunftssicherheit
• Sonstiges wie beispielsweise Zertifizierungen

Bei den Kriterien zur Auswahl ist somit nicht nur der Preis einer Leistung, sondern auch die Bewertung obiger Kriterien zuzüglich der Leistung selbst einzubeziehen. Ein bewährtes Modell zur Ermittlung eines sogenannten Bestbieters ist beispielsweise folgendes:

• Aufteilung der Bewertung der Kriterien „Preis“, „Leistung“ und „Sonstige Kriterien“ z.B. im Verhältnis 50%:30%:20%
• Die Kategorie „Preis“ wird beispielsweise mit 50% für den Billigstbieter, 45% für den zweitbilligsten Bieter usw. festgelegt oder die Bewertung wird linear zwischen billigstem (50%) und teuerstem (0%) Anbieter errechnet
• Für die Kategorie „Leistung“ wird ein Leistungskatalog mit Punktebewertung definiert. Optional zu erbringende Leistungen werden gewichtet und summiert; die maximal mögliche Summe an Bewertungen entspricht 30%, darunter wird linear gerechnet
• Für die Kategorie „Sonstiges“ werden verschiedene Kriterien angeführt und mit Punkten bewertet, beispielsweise die Anzahl an vorhandenen Referenzen für ähnliche Projekte. Die Berechnung erfolgt sinngemäß wie in der Kategorie „Leistung“

Mit einem derartigen System kann anhand festgelegter Kriterien und deren Gewichtung eine nicht nur den Preis, sondern eine auch andere wesentliche Kriterien umfassende Beurteilung erzielt und daraus ein Bestbieter ermittelt werden (siehe auch ergänzend 3.5 Total Cost of Ownership).

Was ist die Beauftragung eines Projekts?

Die Beauftragung eines Projekts ist ein formaler und rechtsverbindlicher Akt. Abhängig vom Auftraggeber sind eventuell bestimmte Vorgangsweisen und Gesetze einzuhalten, beispielsweise im Bereich öffentlicher Auftraggeber.

Mit der Beauftragung wird festgelegt

• Welcher Leistungsumfang vom Auftragnehmer geliefert wird
• Zu welchen Kosten und innerhalb welcher Zeit dies erfolgen soll
• Wie der Projektverlauf stattfindet (also z.B. wann welche Teilsysteme in Betrieb gehen sollen, an welchen Örtlichkeiten Leistungen erbracht werden müssen, welche Mitwirkungspflichten der Auftraggeber hat etc.)
• Wie die Beurteilung der Lieferungen erfolgt, d.h. welche Tests vorgesehen sind und wie Abnahmen erfolgen
• Welche Schulungen durchzuführen sind und welche Dokumentation zu liefern ist
• Welche begleitenden Tätigkeiten wie z.B. ein Qualitätsmanagement durchzuführen sind
• Welche Personen seitens Auftraggeber und Auftragnehmer Ansprechpartner sind und welche Befugnisse diese im Rahmen des Projekts haben

und dergleichen mehr. 

Verbunden mit der Beauftragung ist auch im Idealfall die Erstellung des Pflichtenhefts, welches ja (siehe 3.2 Modellierung von Informationssystemen – Lasten- und Pflichtenheft)

• die Grundlage für die vertraglich festgehaltenen und bindenden Leistungen eines Auftragnehmers bildet
• „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben“ beinhaltet
• und die Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes und die organisatorische und/oder technische Vorgabe zur Realisierung eines Projekts beschreibt

Was umfasst die Implementierung eines Systems?

Die Implementierung eines Systems umfasst nicht nur die Programmierung von Anwendungen, sondern auch die Installation im Zielsystem und je nach Projekt beispielsweise auch die Migration bzw. Übernahme von bestehenden Daten sowie eventuell notwendige Schulungen, Umrüstungen von Hardware und dergleichen mehr.

Die Programmierung ist jener Teil einer Entwicklung, wo auf Grund der Vorgaben aus den Anforderungen und aus dem Design die Umsetzung in lauffähige Programme und Programmteile erfolgt. Bevor ein System oder ein Teilsystem tatsächlich in Betrieb gehen kann, sind angemessene Tests notwendig.

Modultests werden von den Entwicklern selbst vorgenommen. Dabei wird die Funktion einzelner Module in sich getestet, ohne noch mit anderen Teilen zusammen zu wirken. Die Aussagekraft solcher Tests ist naturgemäß beschränkt, gewährleistet jedoch zunächst das grundsätzliche Funktionieren einer in sich abgeschlossenen Softwareeinheit.

Integrationstests werden ebenfalls noch von Entwicklern selbst durchgeführt, allerdings werden diese auch im Normalfall bereits von einem Tester begleitet. Hier geht es um den Nachweis, dass die Schnittstellen der einzelnen Softwarekomponenten miteinander wie vorgesehen interagieren. Dabei können nicht nur funktionale Anforderungen getestet werden, sondern bereits auch beispielsweise das Zeitverhalten von mehreren, miteinander arbeitenden Modulen.

Systemtests sind die Vorstufe zur Abnahme und Installation eines fertigen Produkts bzw. Teilprodukts. Diese werden von Testern in einer möglichst realen Testumgebung so durchgeführt, als würde es sich um ein in Betrieb befindliches System handeln. Entsprechend umfangreich können die Systemtests ausfallen. Hilfreich für Systemtests sind neben einer möglichst realen Testumgebung beispielsweise auch reale Testdaten, also Daten, die aus dem Echtbetrieb kommen und wo beispielsweise Ergebnisse von Funktionen schon bekannt und nachvollziehbar sind.

Sind die Systemtests bestanden, kann das Produkt in den Echtbetrieb übergehen. Bei einer Neuinstallation ist dazu beispielsweise das Befüllen mit Stammdaten wie Artikel, Kunden, Adressen oder Personen erforderlich. Bei einem Ersatz eines bestehenden Systems müssen die vorhandenen Daten übernommen werden; dabei ist oft eine Konvertierung unterschiedlicher Formate erforderlich (beispielsweise enthält das Altsystem Datumsangaben für Jahr, Monat und Tag in einzelnen Feldern, das Neusystem benötigt Datumsangaben als ein einziges Datumsfeld). Dies wird als Migration bezeichnet.

Wird ein bestehendes System erweitert oder werden einzelne Teile ausgetauscht, spricht man von Integration. Dabei wird die neue Software so in das bestehende System eingebracht, dass der Betrieb a) möglichst kurz unterbrochen und b) die Kontinuität der Systemfunktionen gewährleistet ist.

Begleitende Tätigkeiten sind neben dem Projektmanagement, dem Qualitätsmanagement und dem Testmanagement jetzt auch Themen wie Versionsverwaltung (welche Versionen von welchen Teilen des Systems – also Software, Dokumentation, Testnachweise, … – gehören wie zusammen), Konfigurationsmanagement (welche Software ist mit welchen Komponenten in welcher Kombination wo eingesetzt) oder das Releasemanagement (wann wurde wo welche Version eingesetzt, in welcher Version wurden welche Fehler behoben, …).

Was ist die Abnahme bei einem IS-Projekt?

Systemtests sind die Vorstufe und die Voraussetzung für eine Abnahme. Während des Projekts, spätestens aber zum Projektende, können oder müssen einzelne Ergebnisse oder erbrachte Leistungen durch den Auftraggeber formal abgenommen werden. Meistens sind damit auch vertragliche Vereinbarungen (z.B. ein Übergang in die Gewährleistung) und Zahlungen verbunden.

Nach DIN 69901-5 ist die Abnahme eine „unternehmerische Entscheidung des Auftraggebers, dass ein (Teil-)Ergebnis den Vereinbarungen und Erwartungen entspricht und somit als Grundlage für nachfolgende Prozesse verwendet werden kann und muss.“

Die (End-)Abnahme ist somit jener letzte Meilenstein im Projekt, mit der festgestellt wird, ob bzw. dass ein Projekt zu Ende ist. Nach Abschluss des Projektes weist der Projektleiter im Rahmen einer Projektabnahme daher nach, dass:

• das Produkt alle geforderten Funktionen der Spezifikation enthält
• das Produkt in der vereinbarten Qualität erstellt wurde
• das Budget innerhalb des vereinbarten (oder veränderten) Finanzierungsrahmens liegt
• die Termine innerhalb des vereinbarten (oder veränderten) Zeitfensters liegen

Ein Abnahmeprotokoll beinhaltet somit typisch

• die Beschreibung des abzunehmenden Liefergegenstandes
• gegebenenfalls erkannte (und eventuell zu behebende) Mängel sowie mögliche Vorbehalte bei der Abnahme
• einen Abschlussbericht und einen Erfahrungsbericht
• einen Testbericht über die Abnahme
• einen Nachweis des Projekterfolges = Messung der Zielerreichung
• eine Nachkalkulation (abschließender Soll/Ist-Vergleich)
• die Analyse von Planabweichungen samt Ursachen
• Unterschriften des Auftraggebers und des Projektleiters

Es ist empfehlenswert, die Abnahme als formalen Akt die ganze Projektlaufzeit über bei allen Aktivitäten im Blick zu behalten. Das beginnt bereits mit der Definition der Anforderungen, wo parallel dazu überlegt werden kann und soll, wie die Anforderungen am Ende auf Einhaltung überprüft werden sollen.

Wie definiert der PMBOK Projektmanagement?

Nach DIN 69901 wird Projektmanagement als „die Gesamtheit von Führungsaufgaben, -organisation, -techniken und –mitteln für die Abwicklung eines Projekts“ bezeichnet. Der PMBOK (Project Management Body Of Knowledge) definiert hingegen Projektmanagement als „die Anwendung von Wissen, Fähigkeiten, Werkzeugen und Verfahren auf Projektvorgänge, um die Projektanforderungen zu erfüllen“.

Das PMI (Project Management Institute) unterteilt das Projektmanagement in neun Teildisziplinen, die auch als „9 Wissensfelder des Projektmanagements“ bezeichnet werden. Mit dieser Einteilung wird ein umfassender Überblick über die wesentlichen Teilaspekte des Projektmanagements erreicht.

Integrationsmanagement

Das Integrationsmanagement (Project Integration Management) im Projektmanagement beschreibt die Prozesse, die für eine gute Koordination und Integration der unterschiedlichen Aktivitäten eines Projekts erforderlich sind. Es umfasst die Projektplanentwicklung, die Projektplandurchführung und das Änderungswesen.

Umfangsmanagement

Das Projektumfangsmanagement (Project Scope Management) befasst sich mit der laufenden Planung und Kontrolle des Leistungsfortschritts im Projekt. Im Rahmen des Umfangsmanagements wird in regelmäßigen Abständen überprüft, ob sich das Projekt „auf dem richtigen Weg” befindet. Zum Projektumfangsmanagement gehören die Projektinitiierung, die Inhalts- und Umfangsplanung, die Leistungsdefinition, die Leistungsverifizierung sowie die Leistungsüberwachung.

Zeitmanagement

Das Zeit- und Terminmanagement (Project Time Management) soll sicherstellen, dass ein Projekt termingerecht fertiggestellt wird. Zum Zeit- und Terminmanagement gehören die Vorgangsdefinition, Festlegung der Vorgangsfolgen, Vorgangsdauerschätzung, Terminplanentwicklung und Terminplanüberwachung.

Kostenmanagement

Das Kostenmanagement (Project Cost Management) beschreibt alle erforderlichen Prozesse, die sicherstellen sollen, dass das Projekt im geplanten und genehmigten Kostenrahmen fertiggestellt wird. Zum Kostenmanagement gehören Einsatzmittelplanung, Kostenschätzung, Budgetierung sowie Kostenüberwachung.

Qualitätsmanagement

Das Qualitätsmanagement in Projekten (Project Quality Management) soll sicherstellen, dass die vom Auftraggeber definierten Qualitätsansprüche eingehalten oder sogar übertroffen werden. Dazu gehören Qualitätsplanung, Qualitätssicherung und Qualitätslenkung.

Personalmanagement

Die Hauptaufgabe des Personalmanagements (Project Human Resource Management) ist es, dafür zu sorgen, dass die am Projekt beteiligten Mitarbeiter so effizient wie möglich eingesetzt werden. Dem Personalmanagement können folgende Funktionen und Aufgaben zugeordnet werden: Projektorganisation, Personalakquisition und Teamentwicklung.

Kommunikationsmanagement

Das Kommunikationsmanagement (Project Communications Management) im Projekt hat zum Ziel, sämtliche Projektinformationen rechtzeitig und angemessen zu erstellen, zu sammeln, zu verbreiten, abzulegen sowie zu definieren. Hierzu gehören der Aufbau eines Informations- und Berichtswesens, die Informationsverteilung, die Fortschrittsermittlung sowie der administrative Abschluss.

Risikomanagement

Das Risikomanagement (Project Risk Management) beschreibt sämtliche iterativen Prozesse, die notwendig sind, um Projektrisiken festzustellen, zu analysieren und darauf zu reagieren. Hierzu gehören die Risikoidentifizierung, die Risikobewertung, die Entwicklung von Maßnahmen zur Risikobewältigung sowie die Risikoverfolgung.

Beschaffungsmanagement

Das Wissensfeld Beschaffungsmanagement (Project Procurement Management) beinhaltet die Beschaffung von Waren und Leistungen außerhalb der Organisation sowie die dazugehörige Vertragsgestaltung. In diesen Bereich fallen Beschaffungsvorbereitung, Angebotsvorbereitung, Einholen von Angeboten, Lieferantenauswahl, Vertragsgestaltung und Vertragserfüllung.

Welche Bedeutung hat die Auswahl des Vorgehensmodells in der Planungsphase?

Ab etwa 1970 sind laufend verschiedene Modelle entwickelt worden, um die Vorgehensweise in der (Software-)Entwicklung zu professionalisieren und deren Kosten zu minimieren, von denen hier einige Modelle ansatzweise angeführt werden (siehe dazu auch 3 Planung, Entwicklung und Betrieb von Informationssystemen). Die Auswahl eines der Aufgabenstellung angemessenen Vorgehensmodells ist ein für den Projekterfolg maßgeblicher Schritt in der Planungsphase.

Was ist das Wasserfallmodell?

Eines der ersten und einfachsten Vorgehensmodelle war das sogenannte Wasserfallmodell. Es handelt sich dabei um eine lineare Abfolge der einzelnen Lebenszyklus-Phasen:

Das reine Wasserfallmodell ist für kleine Softwareprojekte im Sinne der Tabelle 1 durchaus geeignet. Für größere Projekte ergeben sich jedoch erhebliche Nachteile:

• Eine Überprüfung des Ergebnisses ist erst am Ende vorgesehen – nicht vermeidbare Fehler in einer oder mehreren Phasen führen zu einem nochmaligen Durchlauf kompletter Abschnitte
• Es wird davon ausgegangen, dass bereits zu Beginn alle Anforderungen feststehen und vor allem, dass sich diese während der Entwicklungsphase nicht mehr ändern, was meist nicht der Realität entspricht

Was ist der Grundgedanke von Wachstumsmodellen in der Softwareentwicklung?

Wachstumsmodelle stellen den Gedanken der Software-Evolution in den Mittelpunkt. Ein System wird nicht von Beginn an vollständig konstruiert, sondern es wächst in einer Reihe aufeinanderfolgender Schritte. Es gibt verschiedene Varianten von Wachstumsmodellen unter verschiedenen Namen, z.B. Versionen-Modell, evolutionäres Modell oder inkrementelles Modell.

Der Grundgedanke ist, dass – ausgehend von einer groben Zusammenstellung der Gesamtfunktionalität des gewünschten Systems – eine Folge von Lieferungen mit Lieferumfang und Liefertermin definiert wird. Jede Lieferung ist betriebsfähig und kann nach Auslieferung sofort in Betrieb genommen werden. 

Erfahrungen mit frühen Lieferungen können bei späteren Lieferungen berücksichtigt werden:

Jede Lieferung wird als mehr oder weniger autonomes Teilprojekt organisiert. Da diese Teilprojekte in der Regel vergleichsweise klein und kurz sind, kann innerhalb einer Iteration ein ergebnisorientiertes Phasenmodell als Vorgehensmodell verwendet werden.

Bei der Definition des Umfangs und der Reihenfolge der Lieferungen wird immer ein schrittweiser Ausbau des Systems bis zum gewünschten Endzustand geplant. Dabei können verschiedene Merkmale schrittweise ausgebaut werden, zum Beispiel die Funktionalität, der Bedienungskomfort, die Leistung oder die Verwendbarkeit. 

In Fällen, wo der Auftraggeber keine Teillieferungen will bzw. wo man nicht mit Teilprodukten auf den Markt gehen kann, kann ein Wachstumsmodell trotzdem sinnvoll eingesetzt werden. Die Lieferungen erfolgen dann intern. Vorteile sind eine bessere Projektkontrolle und lieferfähige Teile, wenn der geplante Liefertermin für das Gesamtsystem nicht eingehalten werden kann.

Was ist das V-Modell?

Ausgehend von der Erkenntnis, dass Fehler typisch auf derselben Abstraktionsebene entdeckt werden, wo diese entstehen, hat sich das sogenannte V-Modell durchgesetzt und weit verbreitet.

Daraus ergibt sich das V-Modell wie folgt:

Beim Vorgehen nach dem V-Modell wird ebenso schrittweise wie in anderen Modellen vorgegangen. Das Modell wird von links oben – beginnend mit dem Projektauftrag und den Anforderungen – nach unten über die Implementierung bis nach rechts oben zur Abnahme durchlaufen.

Die Querverbindungen zeigen an, auf welchen Ebenen Tests durchgeführt werden. Modul-Tests werden gegenüber den Modulspezifikationen durchgeführt. Systemtests beinhalten bereits einzeln getestete (Modultests) sowie im Zusammenspiel getestete (Integrationstests) Teile. Am Ende wird mit einem Abnahmetest die gesamte Funktion des Systems gegenüber den ursprünglichen Anforderungen validiert.

Die aktuelle Version des V-Modells wird als V-Modell XT bezeichnet. Die Bezeichnung XT bedeutet „eXtreme Tailoring“ und bezeichnet damit eine flexible Vorgangsweise, die eine Anpassung des Modells an die jeweils benötigten Randbedingungen – also beispielsweise der Projektgröße – ermöglicht.

Das V-Modell ist ein Leitfaden zum Planen und Durchführen von Projekten. Mit einer V-Modell-konformen Durchführung eines Projekts werden die folgenden Ziele verfolgt:

Minimierung der Projektrisiken: Das V-Modell gibt standardisierte Vorgehensweisen vor, beschreibt die zugehörigen Ergebnisse und die verantwortlichen Rollen. Damit erhöht das V-Modell die Projekttransparenz und verbessert die Planbarkeit von Projekten…

Verbesserung und Gewährleistung der Qualität: Als standardisiertes Vorgehensmodell stellt das V-Modell sicher, dass die zu liefernden Ergebnisse vollständig und von gewünschter Qualität sind. Die durch das Modell definierten Zwischenergebnisse können auf diese Weise frühzeitig überprüft werden…

Eindämmung der Gesamtkosten über den gesamten Projekt- und Systemlebenszyklus: Durch die Anwendung des standardisierten Vorgehensmodells lasst sich der Aufwand für die Entwicklung, die Herstellung, den Betrieb und die Pflege und Wartung eines Systems auf transparente Weise kalkulieren, abschätzen und steuern… 

Verbesserung der Kommunikation zwischen allen Beteiligten: Die standardisierte und einheitliche Beschreibung aller relevanten Bestandteile und Begrifflichkeiten ist die Basis des wechselseitigen Verständnisses aller Projektbeteiligten…(Auszug aus (V-Modell-Autoren, 2012) – V-Modell XT Gesamt Version 1.4).

Interessant und wichtig ist, dass in diesem Modell auch Rollen mit deren Aufgaben und Verantwortungen beschrieben sind.

Das V-Modell kann in Teilen auch iterativ durchschritten werden oder anders formuliert: es dient als Basis für andere Vorgehensweisen. Beispielsweise werden in agilen Vorgehensmodellen die Phasen Anforderungen, Entwurf, Entwicklung bis hin zur Auslieferung lauffähiger Software im Sinne eines Wachstumsmodells mehrfach durchlaufen.