IT-Projektmanagement und Agiles Projektmanagement

Agiles IT-Projektmanagement und klassisches Projektmanagement

Im klassischen Projektmanagement unterscheidet man zwischen 3 Hauptprojekttypen:

Investitionsprojekte
Forschung und Entwicklung ( F & E)
Organisationsprojekte

Viele IT Projekte lassen sich als Forschungs- und Entwicklungsprojekt einstufen, sind aber oft auch Investitionsprojekte.

IT Projekte sind sehr anspruchsvoll, da oft neue Applikationen entwickelt werden,
mit neuen Technologien und unklaren Kundenanforderungen,
die ein sehr dynamischen (agiles) Projektmanagement erfordern.

Die für ein klassisches Projekt erforderlichen Spezifikation und detaillierten Dokumentationen,
sind oft ungenügend und werden während der Projektlaufzeit häufig angepasst und erweitert.
Daher ist im IT- Projektmanagement eher ein dynamisches, bzw. agiles Projekt-Management Konzept erforderlich.

Agiles Projektmanagement in der IT mit SCRUM

Hier bietet zum Beispiel das amerikanische Konzept SCRUM neue Ansätze um die agile Softwareentwicklung,
ebenso agil während des gesamten Projektablaufs zu gestalten und zu managen.

Im SCRUM Prozessmodel findet man nicht die statischen Phasenabläufe und ein fest definiertes Endziel.
Das SCRUM Projektmanagement -Konzept ist während des Projektablauf ausbaufähig und kann sich dynamisch
an neue Kundenanforderung anpassen,
wenn dieser eine inkrementelle Software nach jedem SPRINT zur Ansicht und Prüfung bekommt.

Bei jedem IT-Projekt kann man also abwiegen,
ob die neue zu entwickelnde Applikation eher mit dem klassischen Projektmanagement organisiert werden soll,
oder ob man doch besser ein agiles Projektmanagement startet.

Wobei auch hier gesagt werden muss,
dass auch Kombinationen vom klassischen und agilen Projektmanagement möglich sind.

Klassisches Projektmanagement nach DIN 69 901

Die bereits oben beschriebenen klassischen Projektarten erfüllen alle gleiche Anforderungen und gelten daher als Projekt.
Denn diese Vorhaben erfüllen im wesentlichen durch Ihre Einmaligkeit die folgenden Bedingungen:

Sie haben eine Zielvorgabe
Es gibt eine zeitliche, finanzielle, personelle und weitere Begrenzungen
Sie unterschieden sich gegenüber anderer Vorhaben
Und beinhalten eine projektspezifische Organisation

Wenn also eine Aufgabe diese Kriterien erfüllt, gilt dies im Allgemeinen als Projekt.

Kunden die nun Ihre Vorstellungen und Wüsche im Lastenheft
oder der Spezifikation dem Auftraggeber mitteilen,
erwarten im Pflichtenheft vom Auftragnehmer schon eine Aussagekräfte Beschreibung,

wie etwas gemacht wird ?
wie lange es dauert ?
und vor allem, wie viel es kostet ?

Solche Aussagen jedoch auf recht grob verfasste Lastenhefte oder der Spezifikation zu erstellen ist schwierig,
da man oft den gesamten Umfang eines IT-Projektes, zu Beginn nicht bis ins kleinste Detail planen kann.

Daher wird im klassischen Projektmanagement zu Beginn eine umfangreiche Situationsanalyse betrieben,
um die Anforderungen zu konkretisieren und die Projektziele so eindeutig wie möglich zu definieren.

Die Machbarkeitsstudie zu Projektbeginn

Je komplexer ein Projekt ist,
desto wichtiger ist eine ausführliche Machbarkeitsstudie zu Beginn des Projektes.

Mit Hilfe der Machbarkeitsstudie soll beim Projekt unter anderem ermittelt werden:

Ob und wie es technisch machbar ist. Welche Technologien sollen eingesetzt werden? und welche sind schon vorhanden?
Personelle Kapazitäten (kann man mit vorhanden Kapazitäten arbeiten? oder werden noch Neue benötigt?.. wenn ja wie viel?)
Finanzielle Machbarkeit. Wie viel Kapital wird benötigt ? um alle Ressourcen (personell und materiell) abzudecken
Rechtliche Machbarkeit. Besonders im IT sind oft internationale rechtliche Bedingungen zu beachten, da die Technologien Länderübergreifend eingesetzt werden
Gesellschaftliche Machbarkeit. Hier geht es nicht nur um moralische Grundlagen, sondern auch um technologische Aspekte

Die Steakholder- und Risikenanalyse im Projektmanagement

Seine Steakholder zu erkennen und zu analysieren ist sehr wichtig,
da diese sowohl am Erfolg, aber auch am Untergang (scheitern) eines Projektes beteiligt sein können.

Als Steakholder gilt im allgemeinen jeder,
der in irgendeiner Beziehung mit dem Projekt in Verbindung steht.
Die Steakholder können als Fach- oder Machtpromoter auftreten aber ebenso auch ein Projektgegner sein.
Je nach Projektart ist es also sehr wichtig seine Steakholder zu kennen
und diese auch während des gesamten Projektablauf im Auge behalten.

Beim Risikomanagement betrachtet man noch weitere Faktoren,
die mit dem Projekt in Verbindung stehen.

Wenn man alle möglichen Risiken zum Projekt erkannt und analysiert hat,
geht es im nächsten Schritt darum, diese Projektrisiken zu minimieren oder besser zu eliminieren.
Aber gegen manche Risiken kann man sich einfach nur absichern (versichern).
Hier kann man im Grunde nur durch gute AGB's die Risikohaftung minimieren
oder gar die Risiken auf andere Vertragsparteien verschieben.

SMART im Projektmanagement

Da jedes Projekt irgendwie immer auf ein bestimmtes Ziel hinaus arbeitet,
bietet sich hier auch die SMART Methode an, um Projektziele klar zu definieren.

Diese SMART Projektziele sollten sein:
S = spezifisch (specified)
M = messbar (measurable)
A = attraktiv ( archiable)
R = realistisch (realistic)
T =Terminiert (timebased)

Mit Hilfe der SMART Methode, erleichtert man die Definition eines Projektes.
Jede Kundenanfrage wird dadurch transparenter und für jeden klar definiert.
Also jedes Projektziel,
evtl. auch jeder Meilenstein im Projekt sollte nach der SMART Methode definiert worden sein.

Verträge bei Projekten

Sicherlich gibt es im allgemeinen nur wenige Ausnahmen, wo Verträge einer Schriftform bedürfen.
Projekte sollten jedoch schon aus Prinzip bestimmte Vertragsgrundlagen beinhalten,
damit beide Seiten (Auftraggeber & Auftragnehmer) eine transparente Zusammenfassung und Übersicht haben,
womit leichter nachvollzogen werden kann,
ob die vertraglichen Anforderungen mit dem Projektziel erfüllt wurden.

Datenschutz und internationale Rechte erschweren die Softwareentwicklung immens.
So manch ein IT-Projekt hat mehr Zeit in Anspruch genommen,
um die rechtliche Grundlage zu schaffen, als die Entwicklungszeit selbst.

Es gibt also viele Gründe, einen Fachanwalt die rechtlichen Aspekte betrachten zu lassen
und diese bei den (IT-) Projektverträgen mitwirken zu lassen.

Im allgemeinen gibt es bei Projekten:
Kaufverträge, Werkverträge und Dienstverträge,
welche je nach Projektart entsprechend Umfangreich sein können,
oder durch andere Projektverträge ergänzt oder erweitert werden.
Somit kann schon die Kundenspezifikation (Lastenheft),
welche den groben Projektumfang widerspiegelt, ein Bestandteil vom Projektvertrag sein.