Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.10.1994

Coaching sichert den Projekterfolg ab

Peter Windhoefel

Berater fuer Informations-Management in Dossenheim

Neustart nach verpatzter Client-Server-Migration" - unter dieser Ueberschrift praesentierte die COMPUTERWOCHE in ihrer Ausgabe vom

2. September 1994 die Erfahrung eines Hamburger Adressverlages, der mit einem Client-Server-Projekt gescheitert ist.

Das ist keine Sensation, denn leider kommt so etwas in unserer Branche immer noch ziemlich haeufig vor. Ueberraschend ist schon eher, dass die Nachricht der CW eine Titelstory wert ist, zumal ja gerade diese Zeitung in den letzten zwei bis drei Jahren viel dazu beigetragen hat, Client-Server-Loesungen zumindest publizistisch voranzutreiben.

Dennoch bestaetigen die Erfahrungen des Hamburger Unternehmens exemplarisch eine Binsenweisheit, die mancher C/S-Begeisterte in der Vergangenheit nicht immer wahrhaben wollte: Client-Server- Projekte erfordern genausoviel methodisches Vorgehen, professionelles Projekt-Management und fachlich-inhaltliche Vorbereitung wie jedes andere IV-Projekt in einer x-beliebigen konventionellen Umgebung auch.

Aber der Fall zeigt noch etwas anderes, weniger Offensichtliches, naemlich die Gefahren, die sich aus einem Projekt-Management ergeben koennen, das nicht unbeeinflusst, nach innen und aussen unabhaengig und objektiv agieren kann.

Versetzen Sie sich einmal in die Lage des externen Projektleiters, der fuer sein Softwarehaus oder Beratungsunternehmen ein Projekt wie das in Hamburg betreut. Was tun Sie, wenn Sie merken, dass Ihr Vorhaben in eine Schieflage geraet, weil die konzeptionelle Basis fehlt? Thematisieren Sie dieses Problem? Auch wenn Sie wissen, dass dann ein millionenschwerer Auftrag zurueckgestellt, vielleicht sogar eingefroren wird, weil die Erarbeitung eines Pflichtenheftes etliche Monate dauern wuerde? Auch wenn Ihr Auftraggeber alles ganz anders sieht als Sie? Wenn Ihre Wettbewerber nur darauf warten, den Auftrag fortzufuehren? Wenn noch nicht einmal Ihr eigenes Management hinter Ihnen steht, sondern nur an den Umsatz denkt, der gefaehrdet erscheint?

Auch als interner Projektverantwortlicher braucht man Mut, um ein Projekt als gefaehrdet zu melden. Politische Ueberlegungen, Gesichtsverluste gegenueber der Fachabteilung, Budgetfragen sind nur einige Stichworte, um das Dilemma der internen Projektleiter bis hin zum IV-Verantwortlichen zu umreissen.

Solche Ueberlegungen scheinen allerdings bisher nur in den wenigsten Unternehmen angestellt zu werden. Immer wieder findet man als Projektleiter oder -koordinator den Mitarbeiter eines Softwarehauses oder Beratungsunternehmens, der natuerlich - siehe oben - in mancher Hinsicht grosse Schwierigkeiten hat, erkannte Probleme offen anzusprechen.

Wen wundert es da, dass in solchen Faellen die Loesung nur zu oft darin besteht, weitere Mitarbeiter des Beratungsunternehems einzusetzen oder zu guter Letzt die gegenseitigen Schuldzuweisungen beginnen. Etwas aehnliches scheint sich auch in dem Hamburger Projekt abgespielt zu haben. Welche Konsequenzen sind zu ziehen?

Andere Unternehmen haben vergleichbare Schwierigkeiten in der Zusammenarbeit mit externen Dienstleistern durch ein

"Projekt-Coaching" in den Griff bekommen. Dabei wird den internen und externen Projektleitern ein Berater zur Seite gestellt. Dieser soll das Projekt nicht nur durch seinen Erfahrungshorizont und sein methodisches Handwerkszeug befruchten, sondern vor allem durch seine Objektivitaet und Unabhaengigkeit verhindern, dass sich Interessenkonflikte und Durchsetzungsprobleme der beschriebenen Art ergeben.

Coaching eignet sich fuer alle Projekte von einem bestimmten Mindestumfang an aufwaerts. Vor allem fuer sehr grosse, langlaufende Vorhaben kommt als Alternative ein "Projekt-Audit" in Frage. Dabei wird in regelmaessigen Abstaenden zirka ein- bis zweimal jaehrlich der Stand und der Fortschritt eines Projektes ueberprueft. In zirka drei bis fuenf Tagen werden alle vorliegenden Spezifikationen, Analysen und Zwischenergebnisse betrachtet, der Restaufwand nach der Function-Point-Methode ermittelt und mit der aktuell vorliegenden Planung abgeglichen.

Das Ergebnis ist eine objektive, anbieterunabhaengige Momentaufnahme des Erreichten und der noch umzusetzenden Plaene, die dem IV-Management eine fundierte Grundlage fuer das weitere Vorgehen liefert. Auch in dem gescheiterten Client-Server-Projekt in Hamburg haette durch ein solches Audit das Schlimmste verhindert werden koennen.

Wohlgemerkt: Es geht nicht darum, den Projektleitern Unfaehigkeit oder Boeswilligkeit vorzuwerfen. Aber dass diese Mitarbeiter den geschilderten Zwaengen unterliegen, dass die Versuchung oft gross ist, Probleme schoenzurechnen oder zu verschweigen, das wird niemand bestreiten, der einmal die Verantwortung fuer ein groesseres Projekt getragen hat. Die Rechnung dafuer zahlt letztlich der Anwender, der seine Forderungen in der Software nicht wiederfindet.