IM Information Management und Consulting, 4/2012 - Avantum.de

IM SCHWERPUNKT | Thema
Pragmatisches
IT-Projekt- und Change
Management
Ursachen beeinflussen und Wandel bewirken
STEFANIE BöCKMANN UND DIRK BöCKMANN, AVANTUM CONSULT AG
32 IM information Management und Consulting 04 | 2012
Bildnachweis: Fotolia

Im Unternehmensalltag nehmen IT-Projekte mehr Platz
ein und Projektmanagement ist häufig der kritische
Erfolgsfaktor. Erfolgreiches Projektmanagement muss
fokussiert, situationsspezifisch und frühzeitig erfolgen
– kurzum: pragmatisch. Für den Projektleiter gilt es
in jeder Projektphase, die richtigen Methoden sachlich
und zwischenmenschlich einzusetzen und gleichzeitig
mit einem geplanten Change-Prozess die Anpassung des
Organisationsverhaltens an das Zielverhalten einzuleiten.
Nur so kann der Projektleiter den späteren Projekterfolg
bewirken.
1. Projektmanagement und Projekterfolg stehen
in einem klaren Ursache-Wirkungs-Zusammenhang
Projekte sind immer mehr zu einem festen Bestandteil
der Arbeitsorganisation in Unternehmen geworden.
Laut einer Studie [1] der deutschen Gesellschaft für
Projektmanagement wird die Projektarbeit in deutschen
Unternehmen weiter an Bedeutung gewinnen
und sich immer mehr in den Unternehmen unterschiedlichster
Größe verankern. Projekte sind also ein
probates Mittel, um organisatorischen Anpassungsbedarf
in immer volatileren Umfeldern Realität werden
zu lassen. Dagegen zeigen zahlreiche Erfahrungen der
vergangenen Jahre, dass insbesondere viele IT-Projekte
scheitern oder aus dem Ruder laufen. Die in
vielfältigen Studien identifizierten Ursachen wie zum
Beispiel unklare Ziele, nicht ausreichende Ressourcen
oder schlechte Kommunikation können im Projekt
durchaus umsteuert und somit vermieden werden.
Die genannten globalen Meta-Ursachen helfen beim
konkreten Management eines Projektes jedoch wenig.
Vor diesem Hintergrund ist pragmatisches Projektmanagement
eines der zentralen Themen, die zum Erfolg
eines Projektes beitragen können. Unter Pragmatismus
verstehen wir, dass die Managementmethoden
sehr konkret statt unfokussiert, situationsspezifisch
statt allgemeingültig und frühzeitig, das heißt bevor
eine Ursache für ein Problem entstehen kann, eingesetzt
werden. Doch beginnen wir am Anfang:
Projekte sind klar definiert. Ein Projekt hat demnach:
- ein eindeutiges Ziel
- Begrenzungen bezüglich Zeit, Ressourcen und
Kosten
- temporäre Strukturen (Projektstrukturen)
- einen neuartigen/einmaligen Charakter
KURZ UND BÜNDIG
IM SCHWERPUNKT | IT-Projekte
Die Schaffung und/oder Veränderung der Informationsinfrastruktur
durch die Implementierung neuer
Hard- oder Softwarekomponenten, häufig gekoppelt
an die Modifikation organisatorischer Praktiken, ist
dabei das generelle Ziel von IT-Projekten. Wir fokussieren
nachfolgend auf Softwareprojekte, weil sie häufig
umfangreichere Auswirkungen auf die Prozesse
und Strukturen einer Organisation haben.
In der Praxis hat sich die Untergliederung der Software-Projekte
in folgende Phasen bewährt:
- Projektinitialisierung
- Analyse
- Konzeption
- Realisierung
- Implementierung
Die Abbildung 1 zeigt die Inhalte und Ergebnisse der
einzelnen Phasen.
Je nach Projektgröße und -inhalt fallen die einzelnen
Phasen in ihrem Umfang unterschiedlich aus, sie
müssen aber in jedem Fall vollständig und gründlich
abgearbeitet werden, um ein erfolgreiches Projekt
sicherzustellen. Denn die Krux liegt in folgender
Kausalität: Oberflächlichkeiten und Unterlassungen
in frühen Projektphasen verursachen Probleme in
nachgelagerten Projektphasen. Eine Projektteam-Besetzung,
die vom Kompetenzprofil und Sozialverhal-
In Projekten wird über einen bestimmten Zeitraum eine
Lösung erarbeitet und das Verhalten der Organisation
an diese neue Lösung angepasst. Da Projekte zeitlich,
ressourcen- und kostentechnisch begrenzt sind, unterscheiden
sie sich maßgeblich von dem klassischen
Managementansatz. Da der Inhalt klar beschrieben
und für den Bestand der Organisation häufig von herausragender
Bedeutung ist, ist dem Projekterfolg eine
herausgehobene Bedeutung beizumessen. Der Beitrag
beschreibt, welche Phasen ein Projekt durchläuft und
welche Managementmethoden dem Projektleiter helfen,
den Projekterfolg zu bewirken.
Stichworte: Projektmanagement, Softwareentwicklung,
Managementmethoden, Change Management,
Teambuilding
IM information Management und Consulting 04 | 2012
33

IM SCHWERPUNKT | IT-Projekte
Inhalte
Ergebnisse
Projektinitialisierung
Zusammenstellung
des
Projektteams
Definition der
Erwartungshaltung
Definition der
Arbeitsteilung
Definition der
Projektziele
Erstellung des
Projektplans
Einrichtung der
Projektinfrastruktur
Arbeitsfähiges
Projektteam
Abgestimmter
Projektplan
Bekannte Ziele und
Erwartungen
Analyse
Analyse der IST-
Prozesse inkl.
Verantwortlichkeiten
Analyse der
bestehenden
Infrastruktur/ der
bestehenden
Schnittstellen
Analyse der
Datenqualität aus
den Vorsystemen
Aufnahme und
Verfeinerung der
Anforderungen
Dokumentierte und
im Projektteam
verabschiedete
IST-Situation und
Ziel-/Soll-Situation
ten der Aufgabenstellung nicht gewachsen ist, wird
sich durch die Analyse-, vielleicht auch noch durch
die Konzeptionsphase „schummeln“ können, spätestens
bei der Realisierung offenbart sich dann die
Untauglichkeit der Lösungsansätze.
Die Person, die den Erfolg ganz maßgeblich bewirken
kann, ist der Projektleiter. Er ist die zentrale Person,
die ganz nah am Kern-Projektteam dran sein und
dann permanent evaluieren muss, ob alle Ingredienzien
für den Schritt in die nächste Phase vorliegen.
Seine Maßnahmen müssen ganz konkret sein, jedoch
wirken sie häufig „nur“ indirekt (durch das Kern-
Team), was manche Projektleiter mit einer geringen
Wertschöpfung verwechseln.
Wir behaupten also: Ein guter Projektleiter ist Ursache
des Projekterfolgs. Den Auftrag an ihn kann man
prägnant zusammenfassen: BE CAUSE.
2. Jede Projektphase stellt spezifische Anforderungen
und erfordert den Einsatz adäquater Managementmethoden
Jede Projektphase hat ihre eigenen Charakteristika.
Durch die spezifischen Ziele und Risiken verlangt
jede Phase von dem Projektleiter ein entsprechend
34 IM information Management und Consulting 04 | 2012
Konzeption
Ableitung der
inhaltlichen
Anforderungen in
ein technisches
Umsetzungskonzept
Ableitung von
Umsetzungsmodulen
Erstellung eines
Test-, Trainingsund
Roll-out-
Konzeptes
Ableitung von
organisatorisch
notwendigen
Veränderungen
Beschriebenes und
verabschiedetes
Umsetzungskonzept
Test-, Trainingsund
Roll-out-Plan
Realisierung
Prototypische
Umsetzung der
Module
Abstimmung der
Prototypen
Finalisierung und
Erstellung der
releasefähigen
Module
Integration der
einzelnen Module
Integrationstests
Abbildung 1: Inhalte und Ergebnisse der einzelnen Projektphasen
Implementierung
Durchführung von
benutzerspezifischen
Trainings
Roll-out des
Release
Begleitung der User
in der Anwendung
Verankerung von
begleitenden
organisatorischen
Prozessen
Funktionsfähiges In der Organisation
Release, das alle verankertes und
Anforderungen angenommenes
abbildet und für den
Roll-out bereitsteht
System
unterschiedliches Handlungs- und Verhaltensrepertoire.
Hinzu kommt, dass sich das Verhalten des
Kern-Teams auch über mehrere Phasen entwickelt
und somit volatil ist. Der so genannte Team-Lebenszyklus
ist somit ein wesentlicher Kontextfaktor, den
der Projektleiter bei der Planung seiner Maßnahmen
berücksichtigen muss. Der Team-Lebenszyklus beinhaltet
die Stadien Forming (Kennenlernen), Storming
(Konfliktpotenzial), Norming (Kooperationspotenzial)
und Performing (Flowpotenzial). Die Merkmale
der einzelnen Stadien sind in der Abbildung 2 dargestellt.
Darüber hinaus muss der Projektleiter die Verankerung
des neuen Systems in der Organisation immer
im Blick haben. Die Anpassung der Organisation
an den veränderten Zielzustand ist ein Prozess, der
schrittweise eingeleitet werden muss. Je umfassender
die Veränderungen sind, desto stärker muss der
Change-Management-Prozess in das Projektmanagement
mit eingebunden sein. Die Abbildung 3 zeigt
einen solchen Change-Management-Prozess.
Somit erfordert jede Phase im Projekt unterschiedliches
Handeln des Projektleiters. Im Folgenden werden
die einzelnen Phasen bezüglich der Risiken, der
Phasen des Team-Lebenszyklus und der Handlungs-

optionen/Methoden für den Change-Prozess näher
betrachtet.
2.1 Projektinitialisierung
Das Ziel dieser Phase ist es, die angestrebten Projektergebnisse
zu spezifizieren (inhaltlich, terminlich,
zulässiger Aufwand), die Projektorganisation und die
Verfügbarkeit von Ressourcen verbindlich zu vereinbaren
und die rechtzeitige Verfügbarkeit der Projektinfrastruktur
zu vereinbaren. Am Ende dieser
Phase muss das Projektteam arbeitsfähig sein und
die Projektziele und die Erwartungshaltung des
Kunden kennen.
Ist der Change-Aspekt umfangreich, muss in der
Projektinitialisierung ebenfalls der Change-Management-Prozess
„aufgegleist“ werden. Das
heißt, die Initialisierung startet und der Wandlungsbedarf
und die Wandlungsträger in der „neuen“
Organisation müssen mit dem Kern-Team und dem
Auftraggeber spezifiziert werden. Als komplexe Pro-
Situationsbeschreibung
I
Forming
„Kennenlernen“
Offenheit, Zurückhaltung,
Neugier der Kern-Team-
Mitglieder
Missverständnisse zwischen den
Teammitgliedern
Vorsichtiges gegenseitiges
Abchecken im Team
Unsicherheit einzelner
Teammitglieder
Kleines bisschen Stress beim
Projektleiter
II
Storming
„Konfliktpotenzial“
Jeder positioniert sich
(Rolle, Reich …)
Schwächen werden bei den anderen
Teammitgliedern gesucht
Teammitglieder sind auf der Suche
nach Führung
Machtspiele und
Absicherungsmentalität einzelner
Teammitglieder
Ego geht vor Team
Methoden- oder Tooldiskussion
Hilflosigkeit, Druck bei Projektleitung
jekte gelten die Projekte, bei denen der Zielzustand
variabel ist, der Umsetzungsprozess gestört wird und
Rückschläge erleidet (Punkt 3 in Abbildung 4). Punkt
1 und 2 bilden in der Abbildung 4 einfache beziehungsweise
anspruchsvollere Veränderungsprozesse
ab, die ein definiertes Ziel haben und sich lediglich
im Umsetzungsverlauf etwas unterscheiden (geradlinig
im Vergleich zu unstetig). Projekte, die dem 4.
Fall in Abbildung 4 entsprechen, werden in der Regel
nicht zu Ende geführt. Sie haben unklare, mehrdeutige
und variable Ziele – der Veränderungsprozess ist
unmöglich.
IM SCHWERPUNKT | IT-Projekte
Die typischen Risiken in dieser Phase sind, dass die
Erwartungshaltung des Auftraggebers sich nicht mit
dem Ziel- und Prozessverständnis des Projektteams
deckt und dass die Ziele nicht messbar bezüglich Zeit,
Kosten und Inhalt sind. Darüber hinaus sind als Risiken
die unvollständige Aufgabenplanung sowie die
unrealistische Zeitplanung zu nennen.
Da das Projektteam sich während der Projektinitialisierung
in der Forming-Phase befindet – sich also sel-
Ein guter Projektleiter ist Ursache des Pro-
jekterfolgs. Den Auftrag an ihn kann man
prägnant zusammenfassen: BE CAUSE.
ber erst findet –, kann es in dieser Phase ebenfalls dazu
kommen, dass das Projektteam keine arbeitstaugliche
Beziehungsebene findet.
III
Norming
„Kooperationspotenzial“
Projektfortschritt erkennbar
Diskussion über die Sache
(Zieldefinition) im Team
Claims werden abgesteckt von
den Teammitgliedern
Kommunikation innerhalb des
Teams funktioniert
Projektleiter fühlt sich etwas
besser
Projektleiter kann
Steuerungsfunktion wahrnehmen
Abbildung 2: Der Team-Lebenszyklus im Überblick
IV
Performing
„Flowpotenzial“
Team geht vor Ego,
„ganzheitliches Denken“
Gefahren werden antizipiert
Zusammengehörigkeitsgefühl,
„hohe Kohäsion“
Volle Konzentration auf
Projektziele
Große Projektfortschritte
Gegenseitige Wertschätzung
Projektleiter muss auf
Bodenhaftung achten
Um den genannten Risiken entgegenzuwirken, gibt es
für den Projektleiter verschiedene Methoden/Werkzeuge,
die er verwenden kann. Diese gliedern wir in
logische und psychologische Methoden.
Logisch:
Für das Abgleichen der Erwartungshaltung von Projektteam
und Auftraggeber und zur genauen Zieldefinition
ist die Durchführung eines Projekt-Kick-offs
zu empfehlen. Dieser Workshop wird zusammen mit
dem Auftraggeber vorbereitet und mit dem gesamten
Projektteam durchgeführt. Darüber hinaus hat sich
IM Information Management und Consulting 04 | 2012 35

IM SCHWERPUNKT | IT-Projekte
die Erstellung eines Projekthandbuchs bewährt, in
dem Ziele, Erwartungen, Projektorganisation, Projektinfrastruktur,
Kommunikationsregeln und Weiteres
festgehalten werden und für alle Teammitglieder
nachlesbar sind. Um eine unrealistische Zeitplanung
und unvollständige Aufgabenplanung zu vermeiden,
muss ein Projektplan erstellt werden, der mit dem
Somit erfordert jede Phase im Projekt unter-
schiedliches Handeln des Projektleiters.
Team und dem Auftraggeber abgestimmt und verabschiedet
wird. Hierbei ist es wichtig, dass im Zweifel
der Umfang bei nicht haltbaren Endterminen in
Abstimmung mit dem Auftraggeber reduziert wird.
Psychologisch:
Der Projektleiter muss in der Projektinitialisierung
dem Projektteam Orientierung geben. Er muss die
Aufgabenbereiche genau strukturieren und immer
alle Teammitglieder gleichwertig und umfassend
informieren. Auch die Schaffung eines Kommunikationsraumes
ist in dieser Phase besonders wichtig.
Um das Forming des Teams zu erleichtern, können
teambildende Events durch den Projektleiter angeregt
und organisiert werden, damit sich das Projektteam
besser kennenlernt.
36 IM information Management und Consulting 04 | 2012
2.2 Analyse
Abbildung 3: Der Change-Management-Prozess im Überblick
Das Ziel der Analysephase ist das Verstehen der
zugrunde liegenden Prozesse (IST-Situation) und der
Anforderungen an das zukünftige Softwaresystem.
Hierbei muss in der Analyse darauf geachtet werden,
ob es sich um beispielsweise eine Einführung einer
(adaptierten) Standardsoftware oder um die
Implementierung einer Individualsoftware
handelt. Wie Abbildung 5 zeigt, muss der
User bei Implementierung einer Standardsoftware
das System erlernen und sich daran orientieren
beziehungsweise sich stark an dieses
System anpassen – die Analysephase ist weniger
aufwändig, dafür muss der Fokus auf das Change
Management verstärkt werden. Handelt es sich bei
der Implementierung um eine Individualsoftware,
muss der Entwickler den User verstehen und den
Userprozess in dem System abbilden – die Analyse
muss wesentlich intensiver und aufwändiger gestaltet
werden, das Change Management wird in der Regel
einfacher gestaltet sein.
Die Gefahr bei der Analyse ist, dass die Anforderungen
in Breite und/oder Tiefe unvollständig aufgenommen
und die Bedarfe falsch interpretiert werden.
Das Team befindet sich in der Analysephase in der
Regel immer noch im Forming-Stadium mit Tendenz
zu der Storming-Phase, in der jedes Teammitglied seinen
Platz im Team sucht.

Der Projektleiter hat hier folgende Handlungsfelder:
Logisch:
In dieser Phase ist es wichtig, ein Prozessmodell beziehungsweise
eine Ablaufbeschreibung zu erstellen und
diese mit dem Auftraggeber und den jeweiligen Projektbeteiligten
abzustimmen. Somit können Missverständnisse
und Lücken identifiziert werden. Die
Erstellung einer Anforderungsliste mit genauen Spezifikationen
und Mock-ups (kleiner Beispielbildschirm
der Software) stellen sicher, dass die Anforderungen
genau verstanden worden sind. In Abbildung 6 ist ein
Beispiel eines Mock-ups dargestellt.
Eine Priorisierung der durchnummerierten Anforderungen
stellt sicher, dass die Bearbeitung in der richtigen
Reihenfolge geplant wird. Das Lastenheft führt
diese Informationen zusammen und wird durch den
Auftraggeber freigegeben.
Psychologisch:
Da sich das Team häufig noch in der Forming-Phase
befindet, ist es Aufgabe des Projektleiters, hier weiterhin
Orientierung zu bieten und eine offene Kommunikation
innerhalb des Projektteams sicherzustellen.
Je mehr sich das Team Richtung Storming entwickelt
und somit jeder Einzelne seine Position innerhalb
des Teams sucht, desto mehr muss der Projektleiter
die Positionierung lenken, Bereiche klar abgrenzen
(Entscheidungen treffen und Position beziehen), das
Team auf das gemeinsame Ziel hinführen, schlichten
und Herr im Ring sein. Dabei sind Einzelgespräche
wichtig, um bei jedem die Einsicht zu fördern, dass
sich alle Projektteam-Mitglieder aus ihrer Sicht rational
verhalten und auch den Projekterfolg wollen – die
Kern-Team-Mitglieder beurteilen den gleichen Sachverhalt
häufig nur unterschiedlich.
2.3 Konzeption
Handelt es sich bei der Implementierung um
eine Individualsoftware, muss der Entwick-
ler den User verstehen und den Userprozess
in dem System abbilden.
1
2
3
4
Ausgangs
-situation
A
A
A
A
Verlauf und
Veränderung
IM SCHWERPUNKT | IT-Projekte
Zielzustand
Ziel der Konzeptionsphase ist die Erstellung und Verabschiedung
eines Lösungsgesamtkonzepts auf Basis
der vorher durchgeführten Analyse. Dieses Konzept
beinhaltet die Untergliederung in einzelne Lösungsbausteine,
die dann den Fahrplan für die Umsetzung
vorgeben, sowie die Test-, Trainings- und Roll-out-
Planung. Parallel muss der Change-Management-Prozess
konzipiert werden.
Hierbei werden die Wandlungsziele festgelegt
und entsprechende Maßnah men
abgeleitet, die wiederum im Lö sungsgesamtkonzept
entsprechend Berücksichtigung
finden.
Typische Risiken sind, dass die Ausbaufähigkeit
des Systems nicht gewährleistet
ist, die einzelnen Lösungsbausteine
nicht integriert sind oder sich Projektbeteiligte
im späteren Projektverlauf
von der Lösung distanzieren, weil sie das Konzept
nicht verstehen/akzeptieren. Das Projektteam befindet
sich häufig in den Endzügen der Forming- mit
starker Distanz zur Storming-Phase.
Für den Projektleiter ergeben sich während der Konzeption
folgende Handlungsfelder:
Logisch:
Das Konzept wird dokumentiert. Hierbei kommen
ähnlich wie in der Analysephase bereits Mockups
oder Beispielrechnungen zum Einsatz. Darüber
hinaus kann die Beschreibung von Use Cases allen
IM information Management und Consulting 04 | 2012 37
Z
Z
Z
Z?
Abbildung 4: Verschiedene Arten von Veränderungsprozessen

IM SCHWERPUNKT | IT-Projekte
Beteiligten helfen, das gleiche
Verständnis aufzubauen.
Ergänzt werden kann dies
durch einen ersten technischen
Prototyp. Um sicherzustellen,
dass alle Projektbeteiligten
zu der konzipierten
Lösung stehen, wird diese
mit dem Auftraggeber und
den relevanten Projektbeteiligten
abgestimmt und
durch diese freigegeben.
Im Anschluss an diese Phase
sollte der Projektleiter nochmals
den Projektplan „reviewen“
und gegebenenfalls be-
züglich der Detaillierung sowie der Meilensteine und
Termine anpassen. Der Plan ist dann anschließend
ebenfalls mit dem Auftraggeber abzustimmen.
Psychologisch:
Der Projektleiter muss Effekte einer möglichen Storming-Phase
nun verstärkt abfangen, indem er noch
mehr von der Ergebnisorientierung zur Mitarbeiterorientierung
wechselt und mit Einzelgesprächen und
partizipativen Methoden die Kohärenz des Teams fördert.
2.4 Realisierung
Der User muss
das System
erlernen
Ziel der Realisierung ist die Fertigstellung des Gesamtsystems,
damit es „live“ gehen, das heißt in die
Organisation implementiert werden kann. Es hat sich
bewährt, die Umsetzung in kleineren Modulen, für
die jeweils alle Soll-Funktionen klar spezifiziert wurden,
zu realisieren. Wichtig ist, dass die Module zu
einer Gesamtlösung integriert werden.
Der Change-Management-Prozess wird in dieser
Phase mobilisiert, das heißt, das Wandlungskonzept
wird kommuniziert und die Wandlungsbereitschaft
und -fähigkeit in der Organisation werden geschaffen.
Darüber hinaus gilt es dann, die einzelnen Aktionen
aus dem Wandlungskonzept zu priorisieren und
umzusetzen.
Diese Phase birgt eine Menge Risiken. Unter anderem
besteht die Gefahr, dass die Realisierung der Detailfunktionen
nicht komplett durchdacht ist beziehungsweise
die Detailfunktionen nicht die Anforderungen
abdecken. Darüber hinaus besteht immer das Risiko,
38 IM information Management und Consulting 04 | 2012
Standardsoftware
Individualsoftware
Abbildung 5: Standardsoftware und Individualsoftware
Der Entwickler
muss den User
erlernen und
abbilden
dass Fehler oder Umsetzungslücken nicht frühzeitig
erkannt werden oder die Module nicht vollständig
integriert sind.
Das Team geht während der Realisierung in die Norming-Phase
über, das heißt, dass die Rollen der einzelnen
Projektteam-Mitglieder gefunden sind und der
Fokus auf der Sache liegt. Zum Ende der Realisierung
folgt dann die Performing-Phase, in der das Team
über dem einzelnen Teammitglied steht und ein sehr
großes Gemeinschaftsgefühl entsteht. Es kann im
Laufe der Phase und des Projektes aber durchaus sein,
dass das Team durch verschiedenste Einflüsse wieder
in vorherige Stadien des Team-Lebenszyklus gelangt.
Für den Projektleiter heißt das bezüglich der Projektsteuerung
Folgendes:
Logisch:
Zur Sicherstellung der eindeutigen Spezifikation der
Detailanforderungen helfen die in der Konzeption
erstellten Use Cases, die dem Projektleiter oder den
Usern eine frühe Kontrolle ermöglichen. Aber auch
Beispielrechnungen helfen, um die Realisierung der
Detailfunktionalitäten zu durchdenken oder um
sicherzustellen, dass die Module vollständig integriert
werden.
Fehler und Umsetzungslücken werden im Wesentlichen
über Prototypen abgefangen. Damit können
Diskussionen effizient und am „lebenden Objekt“
geführt werden. Darüber hinaus helfen Testfälle und
entsprechende Protokolle, Fehler schnell zu kategorisieren
und zu beheben. Eine stringente Umsetzung
wird ebenfalls über die Steuerung mit Wochenzielen
bewirkt. Diese werden aus dem Projektplan jeweils

ollierend für die nächsten 3 Wochen abgeleitet. Jedes
Wochenziel sollte einer Person zugeordnet sein und
innerhalb dieser Woche zu 100 % zu schaffen sein.
Sobald sich die Wochenziele aufzustauen beginnen
(also nicht zu 100 % erledigt werden), hat der Projektleiter
ein qualifiziertes Feedback, das er für die
weitere Steuerung nutzen kann.
Psychologisch:
Das Stadium des Norming bedeutet für den
Projektleiter, dass er sich nun von der Mitarbeiterorientierung
wieder verstärkt in Richtung
Ergebnis-/Sachorientierung bewegt.
Das bedeutet, dass der Projektleiter Aufgaben
delegiert und die Zielerreichung monitort
sowie darüber hinaus den einzelnen Mitarbeitern
durch interne Kommunikation den Blick
über ihr eigenes Aufgabenfeld hinweg ermöglicht.
Aufgabe ist – auch trotz der starken Ergebnisorientierung
– das Teambuilding in dieser Phase.
2.5 Implementierung
Die Implementierung dient dazu, die Lösung in der
Organisation zu verankern und in die operativen Prozesse
zu integrieren.
Dabei spielt das Change Management nun eine große
Rolle, das in dieser Phase die Wandlungsergebnisse in
der Organisation verankert und die Wandlungsbereitschaft
und -fähigkeit absichern muss.
Die Gefahr bei der Implementierung liegt im Wesentlichen
darin, dass die User das System als zu kompli-
IM SCHWERPUNKT | IT-Projekte
ziert empfinden und die Abhängigkeiten der einzelnen
Module nicht nachvollziehen können. Ebenfalls
besteht die Gefahr der Kopfmonopole im Betrieb des
Systems, die der Organisation Flexibilität nehmen.
Darüber hinaus muss der Projektleiter einem unkoordinierten
beziehungsweise chaotischen Roll-out entgegenwirken.
Wir empfehlen jedem Projektleiter, auch sel-
ber Tests durchzuführen, sich also an das Sys-
tem zu setzen und „in die Tasten zu hauen“.
Abbildung 6: Beispiel eines Mock-ups
Das Projektteam ist in dieser Phase idealerweise allerdings
schon früher im Stadium des Performing, in
dem das Team vereint auf das Ziel hinarbeitet und
große Projektfortschritte macht.
Der Projektleiter hat in dieser Projektphase folgende
Methoden:
Logisch:
Die User und Administratoren müssen in den einzelnen
Modulen geschult werden. Dabei ist es wichtig,
eine zielgruppenspezifische Schulung durchzuführen,
um unterschiedliche Schulungsschwerpunkte
setzen zu können. Zusätzlich sollte eine ausführliche
Dokumentation in Form eines Userhandbuchs, einer
technischen Dokumentation und eines Betriebshandbuchs
erstellt werden. Darüber hinaus kann eine
IM information Management und Consulting 04 | 2012
39

IM SCHWERPUNKT | IT-Projekte
Nachbetreuung mit dem Auftraggeber vereinbart
werden.
Neben der Schulung und der Dokumentation muss
ein Roll-out-Plan erstellt werden, der den koordinierten
und für alle Beteiligten nachvollziehbaren Rollout
sicherstellt.
Psychologisch:
Der Projektleiter muss in der Phase, in der das Projektteam
performt, auf die Zeit und das Budget achten
sowie Mitarbeiter spezifisch fördern.
3. Fazit
Durch die prozessuale Betrachtung, die phasenorientiert
bestimmte Methoden empfiehlt, wird deutlich,
was wir mit spezifisch und frühzeitig meinen.
Abschließend wollen wir noch einige Beispiele für
sehr konkretes Verhalten des Projektleiters aufführen.
Für die IT-Projekte ist es sehr wichtig, dass der
Projektleiter nahe an der Umsetzung und nahe an
dem Projektteam ist und es eng begleitet. Konkretes
Verhalten eines Projektleiters meint in diesem
Zusammenhang, dass der Projektleiter zusammen
mit dem Team Open Issues regelmäßig in wöchentlichen
„Jours fixes“ bespricht – hier hat sich als Basis
eine Open-Issue-Liste bewährt. Eine solche Liste gibt
nicht nur dem Projektleiter die notwendige Sicherheit,
dass nichts vergessen wird. Durch das konkrete
Abstimmen erhalten die Teammitglieder auch nach
und nach Einblick in die Aufgaben und Pflichten des
Projektleiters und Verständnis dafür.
Ein weiteres Beispiel ist das Testen. Wir empfehlen
jedem Projektleiter, auch selber Tests durchzuführen,
sich also an das System zu setzen und „in die Tasten zu
hauen“. Anschließend werden gemeinsam die Rückmeldungen
der Tests durchgegangen, priorisiert und
nachgestellt/nachvollzogen. Die Projektteam-Mitglieder
merken, dass der Projektleiter operatives
Einschätzungsvermögen hat, und der Projektleiter
gewinnt eine realistische Einschätzung des aktuellen
Zielerreichungsstandes.
Zusammenfassend kann gesagt werden:
Die Projektleitung und die Methoden müssen an die
Größe und Komplexität des Projektes angepasst sein.
Darüber hinaus muss der Projektleiter in jeder Phase
seine Managementmaßnahmen überprüfen und
anpassen.
40 IM information Management und Consulting 04 | 2012
LITERATUR
[1] Anke Heines, Ergebnisse der Studie Projekte als Erfolgsfaktor, http://
www.gpm-ipma.de/fileadmin/user_upload/Know-How/studien/Projekte_als_
Erfolgsfaktor_Ergebnisse.pdf, 01.10.2012
SUMMARY
Pragmatic IT project and change management – impacting root causes
and ensuring change
IT projects can be found quite often nowadays in daily business life and project
management is one of the most critical success factors for organisational
change. Successful project management must be focused, tailored to the situation
and provide results on time – in short, it demands a pragmatic approach.
The project leader needs to use the adequate tools in each project phase and
needs to initiate the adaption of the organisational behaviour to the target
state. By doing things this way, the project leader can cause the success of the
project. His/Her mission can be summarised as follows: BE CAUSE.
Keywords: Project management, Software development, Management tools,
Change Management, Teambuilding
SERVICE
AUTOREN
KONTAKT
avantum consult AG
Niederkasseler Str. 96
40547 Düsseldorf
Tel.: +49 (0)211 / 6878380
Fax +49 (0)211 / 68783888
post@avantum.de
www.avantum.de
Stefanie Böckmann
Senior Manager
avantum consult AG
Dirk Böckmann
Vorstand – Partner
avantum consult AG