Bei der Planung und Durchführung von Projekten klaffen Theorie und Praxis nicht selten weit auseinander - vor allem dann, wenn der Auftraggeber nicht entsprechend in die einzelnen Schritte der Systementwicklung involviert ist. Gerhard Schelling glossiert seine Erfahrungen mit dem Projektmanagement und bricht eine Lanze für strukturiertes Vorgehen.
Eigentlich sind unsere Probleme unverständlich, da wir seit mehr als dreißig Jahren Anwendungssysteme entwickeln, um Daten zu Informationen zu verarbeiten. Und eigentlich ist es auch einfach, wenn wir nur das Phasenkonzept und die Richtlinien ansehen. Woran liegt es also? Vielleicht daran, daß wir uns wie folgt verhalten?
Scoping: Alles fängt damit an, daß irgend jemand in der Fachabteilung eine vage Idee hat - es sei denn, irgendeine höhere Gewalt erspart uns diese Mühen durch eine unvermeidbare Anforderung oder die wachere Konkurrenz bringt uns in Zugzwang. Bei günstigem Anreizklima entwickelt sich aus der Idee eine noch froschnasse Vorstellung. Finden sich nach eifrigem Suchen ein, zwei oder gar drei vorzeigbare "Nützchen", so reift die Vorstellung zu einem konkreten Vorschlag heran.
Exploration: Nun legen wir los! Ein strategischer Lösungsansatz jagt den nächsten. Statt kritisch Kosten und Nutzen abzuwägen, suchen wir krampfhaft nach einem wohlklingenden und vielversprechenden Namen für das zu projektierende Kind, schwelgen in high-sophisticated Technologien und papieren massenweise Diskussionen. Am Ende dieser lästigen Untersuchungen ringen wir uns durch und empfehlen eine, nein, die einzig mögliche Lösung überhaupt: Kurz und gut, wir wählen diejenige aus, die uns am besten in den Kram paßt.
Functional Specification: Nun gilt es, sachliche Einwände hinwegzufegen und wirtschaftliche Bedenken zu zerstreuen. Denn spätestens jetzt sind wir überzeugt, alles besser zu wissen und zu können als unser Auftraggeber. Seine arbeitsbedingte permanente Nichtverfügbarkeit verbietet ihm jede Art von gestaltender Mitarbeit oder gar Mitbestimmung, was wir durchaus als Wohltat empfinden.
Mit den uns zu Gebote stehenden sprachlichen und technischen Mitteln, gepaart mit einem kräftigen Schuß Arroganz und Ignoranz, nehmen wir dem zukünftigen Benutzer die letzte Chance, den aufhaltsamen Aufstieg der Idee zu einem verwaltbaren Projekt zu verhindern, indem wir die uns gestellte Aufgabe nach unseren Vorstellungen umgestalten und gekonnt unverständlich dokumentieren.
Design: Nachdem der hilflos resignierende Auftraggeber, durch seine Unterschrift sein Schicksal besiegelt und den erlösenden Startschuß gegeben hat, treten wir erleichtert aus der geistigen Windstille, um endlich in die uns gemäße operative Hektik verfallen zu können und mit atemberaubender Schnelligkeit Pläne, Systemteile und Handbücher zu entwerfen.
Development: Dann krempeln wir zuversichtlich die Ärmel hoch und machen uns, von jedem Zweifel befreit und jeglicher Einmischung verschont, ans Werk: Wir versuchen ehrlich, alle Richtlinien einzuhalten, die unsere Arbeit vereinfachen sollen, die sie aber meistens nur umständlicher machen. Wir bemühen uns ernsthaft, alle Methoden und Werkzeuge einzusetzen, die unsere Arbeit erleichtern sollen, sie aber oft nur in die Länge ziehen. Schließlich, eines fernen Tages, ist es dann doch soweit: Das Werk und wir sind fertig.
Startup: Mit Bravour nehmen wir die letzte Hürde der Verwaltungstätigkeiten und übergeben das System dem Rechenzentrum. Stolze Erleichterung kommt auf, in die sich leichte Wehmut und nervöse Sorge mischt. Noch ahnt der Benutzer nichts von seinem Glück! Zuerst erwartungsvoll, dann ungeduldig und letztendlich widerwillig nimmt er sein System in Empfang: Er hat zulange darauf warten müssen, es ist zu teuer und nicht so geworden, wie er es tatsächlich bräuchte.
Morale: Nach anfänglicher Sprach- und Fassungslosigkeit machen wir uns auf die Suche nach dem Schuldigen. Wir selbst können es nicht sein, da wir im Auftrag gearbeitet, nach Vorschrift gehandelt und alle Richtlinien eingehalten haben. Folglich kann die Schuld nur beim Auftraggeber liegen: Er war weder fähig noch willens, uns zu verstehen und mit uns zusammenzuarbeiten, geschweige denn, uns zu vermitteln, was er eigentlich wollte.
Ist es das, was wir unter einem systematischen Vorgehen verstehen, um unsere Aufträge wirkungsvoll und preiswert, fach- und termingerecht, vor allem aber zum Nutzen und zur Zufriedenheit unserer Kunden zu erledigen? Wohl kaum. Was also lernen wir daraus? Es kann eigentlich nur besser werden, wenn wir
- unserem Auftraggeber zuhören (auch wenn Kurt Tucholsky den Menschen als ein Wesen definierte, das nie zuhört) und versuchen, sein Anliegen zu verstehen,
- ihn von Anfang an mit einbeziehen und uns bemühen, ihm unsere Aufgaben und Forderungen verständlich zu machen,
- einen Auftrag nur dann annehmen, wenn er wirtschaftlich vertretbar ist und mit den verfügbaren Mitarbeitern und Mitteln erledigt werden kann,
- Termine, Kosten und Nutzen realistisch schätzen und gemeinsam versuchen, sie einzuhalten,
- dort gezielt Vorschriften, Richtlinien und Empfehlungen beachten, Methoden, Techniken und Werkzeuge einsetzen, wo sie angebracht und wirkungsvoll sind.
Halten wir uns vor Augen, daß ein weiterer Sprung eine bessere Vorbereitung, eine stärkere Absicherung des Erfolges, einen längeren Anlauf und größere Anstrengungen erfordert. Ein Sprung von drei Metern ist zwar eine beachtliche Leistung, aber dennoch ein Mißerfolg, wenn der Graben vier Meter breit ist. Dies alles gilt natürlich und in gleichem Maße auch für solche Aufträge, die wir uns selbst erteilen.