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.
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:
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