HMD 260, 45. Jahrgang, April 2008

IT-Projektmanagement im Wandel

Herausgeber: Karsten Hoffmann, Michael Mörike

Als E-Book bestellen
Gedruckte Ausgabe bestellen
Feedback an den Herausgeber
Zum Inhaltsverzeichnis

Einwurf

von Jutta Eckstein

Na es wird ja auch mal Zeit, dass sich etwas bewegt. Teilweise verhalten wir uns ja immer noch so, als ob wir es nicht besser wüssten: Obwohl eigentlich Allgemeinwissen - sind wir häufig immer noch überrascht oder sogar verärgert, wenn die Kunden im Laufe eines Projektes ihre Meinung ändern. Und trotz dieses Wissens versuchen wir immer noch, die Anforderungen am Anfang des Projektes zu klären, obwohl das größtenteils reine Zeitverschwendung ist, da ja wie gesagt die Kunden es sich nachher eh nochmals anders überlegen. Dieses Umdenken der Kunden liegt zum Teil daran, dass sich die Marktsituation ändert, aber auch daran, dass die Kunden im Laufe des Projektes ein besseres Verständnis über die Möglichkeiten des zukünftigen Systems entwickeln.

Teil unserer Aufgabe ist es, den Kunden dabei zu helfen, ein solch besseres Verständnis zu entwickeln. Das heißt einerseits, dass wir einen Änderungswunsch von Kundenseite erst einmal als ein positives Zeichen begreifen müssen, da darüber eindeutig ein Erkenntnisgewinn ausgedrückt wird. Andererseits bedeutet dies, dass wir diesen Erkenntnisgewinn ermöglichen müssen, und zwar am besten dadurch, dass wir die Kunden immer wieder dazu einladen, Feedback zu dem konkreten System zu geben. Zum konkreten System deshalb, weil wir nicht erwarten können, dass die Kunden in der Lage sind, Feedback in der gleicher Qualität zu einem Stück Papier (sprich Modell, Anforderungskatalog etc.) zu geben wie zu einem lauffähigen System, das sie tatsächlich benutzen und ausprobieren können. Aus diesem Grund ist es essenziell, so früh wie möglich ein lauffähiges System zur Verfügung zu stellen.

Kurzum wir sollten nicht die Zeit am Anfang des Projektes mit der Analyse von Dingen verschwenden, die hinterher sowieso keiner mehr haben will - sondern diese Zeit während der Projektlaufzeit dafür nutzen, um die Moving Targets zu verstehen und unsere Entwicklung (und auch den Projektplan) darauf anzupassen.

Management, vor allem wenn man es in Form von Mitarbeiterführung versteht, bedeutet immer, dass man zu den Mitarbeitern hingeht und diese entsprechend unterstützt. In vielen Projekten hat sich aus diesem Grunde das Management by Walking Around (MBWA) durchgesetzt. In den heutigen globalen Projekten reicht das jedoch nicht mehr aus, d.h., benötigt wird Management by Flying Around (MBFA). Grundsätzlich ist keine Führung möglich, ohne regelmäßigen und direkten Kontakt zu den Mitarbeitern. Dies gilt ganz generell, aber natürlich umso mehr, sobald irgendwelche Probleme auftauchen. Die traurige Nachricht ist die, dass es kein Werkzeug gibt, das uns diese Aufgabe abnimmt.

Apropos Werkzeuge, diese sind ja bekanntlich dafür gedacht, dass sie die Arbeit entsprechend unterstützen. Leider ist auch dies nicht immer gegeben. Immer wieder erlebe ich, dass Werkzeuge aus den unterschiedlichsten Gründen - unternehmensweit - ausgewählt wurden, dabei aber so gut wie nie diejenigen befragt wurden, deren Arbeit diese Werkzeuge nachher unterstützen sollten. Wird ein Werkzeug nicht angenommen, kann man sich sicher sein, dass es nicht daran liegt, weil der entsprechende Anwender nicht "passt", sondern das Werkzeug.

Zurück zu MBFA - die Forderung, dass Management immer auch bedeutet, zu den verschiedenen Projektstandorten zu reisen, macht es nahezu unmöglich, mehrere Projekte parallel zu unterstützen. Auf diese intensive Betreuung könnte dann verzichtet werden, wenn die globalen Projekte wie ein Netzwerk organisiert und nicht zentral koordiniert werden. Professor Erran Carmel von der American University bezeichnet die zentrale Koordination als Stufe II im evolutionären Prozess der globalen Entwicklung - in der Stufe I findet dabei die gesamte Entwicklung nur an einem Standort statt. In der höchsten Stufe, der Netzwerkorganisation, übernehmen laut Carmel:

[...] verschiedene remote Standorte größere Verantwortung für eine große Anzahl von Aufgaben und koordinieren die Aktivitäten untereinander, ohne alle Entscheidungen durch den zentralen Hauptstandort zu schleusen.

Zurzeit befinden sich die meisten Unternehmen in der Stufe I oder II und oftmals werden sie sogar durch ihre eigene Unternehmenspolitik daran gehindert, auf Stufe III zu gelangen. Typischerweise wird z.B. immer das höhere Management an einem Standort - dem Hauptstandort - zusammengezogen.

Das größere Problem bei Multiprojektmanagement sehe ich jedoch darin, dass man sich vorgaukelt, dass man dadurch schneller mehrere Ziele erreichen könnte. Das Gegenteil ist jedoch der Fall. Das kann man sich ganz einfach ausrechnen: Angenommen wir müssen sechs Projekte fertigstellen, die alle eine Projektlaufzeit von einem Monat haben. Wenn wir jetzt alle Projekte parallel machen, werden alle diese Projekte (im besten Fall), na? - genau in sechs Monaten fertig sein. Machen wir nun ein Projekt nach dem anderen, so wird das erste Projekt bereits nach einem Monat einen Geschäftswert erzeugen, das zweite entsprechend nach bereits nur zwei Monaten und selbst das fünfte Projekt wird noch einen Monat vor der ursprünglichen Multiprojekt-Deadline dem Unternehmen einen Gewinn bringen.

Dazu kommt noch, dass die "Umdenkzeit", d.h. die Zeit, die benötigt wird, sich von dem einen in das andere Projekt einzudenken, wesentlich höher ist, als man gemeinhin annimmt. Dadurch verschiebt sich die Fertigstellung von den Multiprojekten nochmals um einiges nach hinten. Aus diesem Grund führt die Strategie der Multiprojekte eher zur Ent- als zur Beschleunigung.

Die größte Herausforderung sehe ich im Projektmanagement jedoch generell darin, sich die häufig (bewusst oder unbewusst) vorherrschende Meinung abzugewöhnen, dass man, gerade wenn es schwierig wird, nicht mehr dem gesunden Menschenverstand (und auch dem Bauchgefühl) vertrauen dürfte, sondern sich an irgendwelche Regeln halten müsste, die nie dem gesunden Menschenverstand auch nur annähernd entsprechen.

Dipl.-Ing. Jutta Eckstein IT communication Gaußstr. 29 38106 Braunschweig je@it-communication.com www.it-communication.com