Mißerfolge bei Anwendungsentwicklungen analysieren:

IV-Projekte nicht am Bedarf vorbei entwickeln

04.11.1988

In einer Reihe von Unternehmen kriselt es seit Jahren: Unternehmensleitung und Fachbereiche sind mit der Leistung der DV unzufrieden, IV-Manager fühlen sich zu Unrecht angegriffen. Hier muß das Zusammenspiel aller Beteiligten neu überdacht werden, betont Helmut Bender.

Noch immer werden die allgemein zu verzeichnenden Fortschritte der Informationsverarbeitung durch das Phänomen Anwendungsstau überschattet. Zwar hat der vermehrte Einsatz von Standardsoftware und die Beteiligung der Fachbereiche mittels der Instrumente der individuellen Datenverarbeitung (IDV) hier für einige Entlastung auf bestimmten Gebieten gesorgt; grundsätzlich jedoch hat sich das Problem nicht gebessert. Denn gerade große Systeme der Informationsverarbeitung, die dem Unternehmen strategische Wettbewerbsvorteile sichern sollen, lassen sich weder kaufen (denn anderenfalls wäre es kein Wettbewerbsvorteil mehr), noch reichen die Möglichkeiten der IDV aus.

In manchem Unternehmen gibt es seit langem Probleme. Unternehmensleitung und Fachbereiche sind unzufrieden, IV-Manager fühlen sich zu Unrecht angegriffen und beklagen ihrerseits die Inkompetenz ihrer Kunden. Es entstehen Spannungsfelder zwischen allen Beteiligten. Diese wiederum wirken sich lähmend auf alle Fortschrittsbemühungen aus und führen zu weiteren Umdrehungen auf der Spirale der Mißerfolge und Frustrationen.

Spannungsfelder sind nicht naturgegeben

Dieses Szenario mit seinen bekannten negativen Auswirkungen ist kein Naturgesetz, wie zahlreiche Unternehmen zeigen, die auf diesem Sektor der Anwendungsentwicklung sehr erfolgreich operieren. Das Problem ist durchaus lösbar, wenn man managementseitig bereit ist, das Zusammenspiel aller Beteiligten unter Berücksichtigung der Unternehmensstruktur neu zu durchdenken. Eine zentrale Bedeutung hat hierbei die richtige Zuordnung von Fach-, Verantwortungs- und Entscheidungskompetenz.

Um Fehler für die Zukunft auszuschließen, muß man sich zunächst mit der Art der Fehler und ihren Ursachen beschäftigen. Dies ist schon deshalb erforderlich, um bei allen Beteiligten später ein gemeinsames Verständnis für die Neuordnung der Zusammenarbeit zu wecken. Eine Analyse der Mißerfolge bei Anwendungsentwicklungen zeigt Gründe, die zum Scheitern führen:

* IV-Projekte werden fachinhaltlich am Bedarf vorbei entwickelt,

* die technische Lösung mißlingt,

* Fehler bei der Projektplanung.

Jeder dieser Gründe für sich führt bereits zu erheblichen Problemen. Oft aber überlagern sie sich; die Katastrophe ist somit vorprogrammiert.

Die Ursachen für diese Fehler lassen sich nicht pauschal diskutieren. Man muß sie im Zusammenhang mit den Phasen eines großen Anwendungsprojektes analysieren.

In Phase 1 wird aus den Unternehmensstrategien und -zielen und aus den Zielbeiträgen der Fachbereiche im Rahmen einer Schwachstellenanalyse der Handlungsbedarf für die IV-seitige Unterstützung einer Neupositionierung des Unternehmens ermittelt. Diese Phase ist von fundamentaler Bedeutung für den Erfolg des gesamten Projektes. Als Ergebnis erhält man die Projektdefinition, in der die strategischen Ziele, das grobe Lösungsmodell, aber auch der quantitative Nutzen in Form von Rationalisierungs- und Opportunitätspotential festgelegt sind. Damit liegt der Rahmen für die weiteren Projektschritte Fachinhaltsbeschreibung und technische Realisierung fest. Sie sind in ihren Freiheitsgraden an diesen Rahmen gebunden.

Da mit dieser ersten Phase bereits der Projekterfolg im Hinblick auf die zu erreichenden strategischen Unternehmensziele vorgeprägt wird, ist die Verantwortung dieser Phase eine unternehmerische Verantwortung. Sie darf und kann nicht delegiert werden, sondern muß dort angesiedelt sein, wo auch alle anderen unternehmerischen Entscheidungen fallen.

Um seiner Verantwortung gerecht zu werden, bedarf der Fachbereich hoher unternehmerischer und organisatorisch-strategischer Kompetenz. Er kann sich zwar über Inhouse-Berater oder Externe Konzepte entwickeln lassen, muß aber selbst beurteilungs- und entscheidungskompetent sein.

Anders sieht es bei der weiteren Projektentwicklung aus. Hier kann die Verantwortung weitgehend an interne oder externe Dienstleister delegiert werden.

Dieser grundsätzliche Zusammenhang wird vielfach übersehen. Entweder findet die organisatorisch-strategische Phase überhaupt nicht statt, oder mit unzureichender Kompetenz in Durchführung und Verantwortung. Dies ist wesentliche Ursache dafür, daß eine Vielzahl von Projekten strategisch und fachinhaltlich am Bedarf vorbei produziert werden.

Die Gründe für das Scheitern der nächsten Phasen, des fachinhaltlichen Detailkonzeptes und der technischen Realisierung liegen auf einer anderen Ebene. Hier handelt es sich oft um interne Probleme des Bereichs Informationsverarbeitung und des Projektmanagements. Vielfach ist es nicht gelungen, Phasenüberlappung mit ihren extremen Negativfolgen zu vermeiden, im Zusammenspiel mit den Anwendern die Benutzerschnittstelle durch ein frühzeitiges Prototyping zu verproben, eine Akzeptanzstrategie für professionelle Methoden des Software Engineerings zu entwickeln und wirksame Instrumentarien für die Projektfortschrittskontrolle einzusetzen. Dies alles führt zu erheblichen Kostenüberschreitungen und Terminverschiebungen. Daraus resultierend werden Projekte unter Zeitdruck instabil in die Produktion übergeben; die Konflikte sind vorprogrammiert.

Mehrkapazitäten führen zu Kommunikationsproblemen

Wichtig ist ferner, Fehlplanungen in den Griff zu bekommen. Diese haben zwei Ursachen. Zum einen werden Planaussagen über Kosten und Termine zu früh gemacht, noch bevor der aufwandbestimmende Leistungsumfang bekannt ist und sich das Projekt in einem planbaren Zustand befindet. Zum anderen unterliegen viele Manager immer wieder der Versuchung, durch massiven Einsatz von mehr Mitarbeitern die Projektlaufzeit deutlich verkürzen zu wollen. Ein sehr gefährliches Unterfangen, weil die dadurch überproportional steigenden Kommunikationsaufwände die Mehrkapazitäten bei weitem aufzehren. Auf diese Weise sind schon viele Großprojekte völlig "out of control" geraten.

In beiden Fällen handelt es sich auch um ein Problem des Verständnisses zwischen Fachbereichsmanagement, IV-Management und Unternehmensleitung. Zu frühe Planaussagen und zu ehrgeizige Termine, beides oft über die Köpfe der verantwortlichen Projektleiter hinweg, werden oft unter hohem Managementdruck und wider besseres fachliches Wissen gemacht. Man weicht einer begrenzten Konfliktsituation heute aus und schafft sich eine wesentlich größere für die Zukunft.

Auf diese Weise entstandene Planungsfehler lassen sich auch nicht durch höhere Arbeitsintensität der Entwickler ausgleichen. Die hier liegenden Reserven werden oft überschätzt, zumal es auch unter den geschilderten Ausgangsbedingungen schwerlich gelingt, eine Eigenidentifikation der Entwickler mit den zu ehrgeizig vorgegebenen Zielen zu erreichen.

Bei der Behandlung der ersten Projektphase, dem organisatorisch strategischen Planungsprozeß muß die Verantwortung dort angesiedelt sein, wo auch die unternehmerischen Entscheidungen fallen. Dies ist aber je nach Organisationsform des Unternehmens sehr unterschiedlich geregelt.

Am weitesten dezentralisiert ist die unternehmerische Verantwortung in der Profit-Center-Organisation einer Holding. Am anderen Ende der Skala steht die hierarchisch-funktionale Organisation mit Vorgesetzten-Orientierung. Dazwischen liegen Mischformen wie die hierarchisch-funktionale Organisation mit Zielorientierung.

Je zentraler ein Unternehmen organisiert ist, desto stärker konzentrieren sich die unternehmerischen Entscheidungen auf die zentrale Unternehmensleitung. Sie muß damit auch entscheidenden Einfluß auf das organisatorisch-strategische Konzept ihrer Fachbereiche nehmen. Diese Aufgabe kann sie aber nur wahrnehmen, wenn sie sich auf fachkompetente und unternehmerisch denkende Inhouse-Unternehmensberater abstützen kann.

Es macht aus einer Reihe von Gründen Sinn, diese Kompetenz im Bereich der zentralen Informationsverarbeitung anzusiedeln. Hieraus wird erkennbar, daß sich gewisse Aufgabenschwerpunkte und das Rollenverständnis der Informationsverarbeitung aus der Führungsphilosophie des Unternehmens ableiten müssen. In stark dezentral organisierten Unternehmen beschränkt sich ihre unternehmerische Verantwortung auf die konzernübergreifende strategische Ausrichtung der Informationsverarbeitung, im zentralistisch geführten Unternehmen muß sie zusätzlich in eine Teilrolle der Unternehmensleitung schlüpfen. Dies ist besonders wichtig beim organisatorisch-strategischen Planungsprozeß der Fachbereiche.

Planungsprozeß benötigt hochqualifizierte Strategen

In beiden Fällen hält die IV als zweite Säule ein Dienstleistungsangebot für Anwendungsentwicklung und RZ-Betrieb vor. Dieses kann im Fall der Holding von den Profit-Centern genutzt werden. Im zentral geführten Unternehmen ist es jedoch für die Fachbereiche verbindlich. Natürlich werden sich auch die Profit-Center der zentralen IV-Dienstleistungen bedienen, wenn diese sich durch hohe Kompetenz auszeichnen und im Vergleich zu den möglichen Alternativen (Markt beziehungsweise eigene IV) Vorteile bietet. Dies ist im übrigen ein nicht zu unterschätzender Produktivitäts- und Qualitätsansporn für eine zentrale IV in einer Holding.

Die Führungsphilosophie des Unternehmens und ihre Konsequenzen für die Zuordnung der Verantwortung strahlt auch auf die personellen Erfordernisse und auf das Zusammenspiel zwischen Fachbereich beziehungsweise Profit-Center, Unternehmensleitung und IV aus. Für den organisations-strategischen Planungsprozeß benötigt der Leiter im Falle des Profit-Centers einen direkt zugeordneten Stab hochqualifizierter Organisationsstrategen, im Falle des weniger selbständigen Fachbereichs einen in allen Fachfragen verzierten IV-Koordinator im unmittelbaren Umfeld des Fachbereichsleiters und die zentrale IV eine Reihe kompetenter Inhouse-Berater mit breitem Erfahrungsspektrum und überzeugender Ausstrahlung.

In allen Fällen gilt der Grundsatz "Klasse vor Masse". Wer hier Kompromisse macht, hat der zentralen Bedeutung dieser ersten Projektphase für den Unternehmenserfolg nicht Rechnung getragen.

Damit ist auch schon die Zusammensetzung des Projekt-Teams skizziert, das in dieser Phase das organisatorisch-strategische Konzept bis zur Projektdefinition erarbeitet. Am Beispiel einer Holding besteht es aus Organisations-Strategen des Profit-Centers und Vertretern seiner betroffenen Fachbereiche. Beratend können auch die Inhouse-Berater der IV hinzugezogen werden.

Die Projektdefinition ist der verbindliche Rahmen für die weitere Arbeit des Teams, das nun, angereichert durch Organisatoren und Anwendungsentwickler des Dienstleisters IV, das fachinhaltliche Konzept entwickelt. Die permanente Beteiligung der Organisationsstrategen des Profit-Centers ist hier nicht mehr erforderlich.

Control-Board überwacht den weiteren Projektverlauf

In der dritten Stufe, der technischen Realisierung, besteht das Team überwiegend aus Mitarbeitern des Dienstleisters; der Fachbereich kommt erst in der Einführungsphase wieder stärker hinzu.

Diese Projektorganisation spiegelt auch sehr deutlich den Zusammenhang zwischen deligierbarer und nicht deligierbarer Verantwortung wider. So liegt folgerichtig die Projektleitung in der Phase 1 beim Profit-Center und für Fachinhaltsbeschreibung und technische Realisierung beim Dienstleister.

Damit nun das Projekt unter Regie des Dienstleisters IV kein Eigenleben entwickelt, wird der weitere Projektverlauf von einem Control Board periodisch überwacht. In diesem Gremium muß unter anderem auch darüber entschieden werden, ob und in welchem Umfang Änderungen und Erweiterungen zugelassen werden. Um vor späteren Überraschungen sicher zu sein, darf diese Entscheidung nur auf der Basis jeweils angepaßter Kosten- und Terminaussagen des Projektleiters getroffen werden.

Gerade dieser Aspekt wird vielfach übersehen. Eine Fülle sogenannter kleiner Änderungen und Erweiterungen summieren sich derart, daß sich der Projektverlauf erheblich verzögert. Gegenseitige Schuldzuweisungen setzen ein, Rechfertigungsaufwendungen entziehen dem Projekt wertvolle Kapazität, und weitere Verzögerungen sind die Folge. All dies läßt sich durch geregelte Entscheidungsprozesse im Control Board vermeiden.

In nahezu allen Unternehmen übersteigen die Projektanforderungen bei weitem das zur Verfügung stehende Budget und die vorhandenen Entwicklungskapazitäten. Ein Großteil dieser Engpässe ließe sich durch eine durchaus mögliche erhebliche Produktivitätssteigerung im Softwareentwicklungsprozeß auffangen. Einige Firmen haben in den letzten Jahren gezeigt, welch große Fortschritte hier möglich sind.

Budget-Engpässe mit allen Kräften vermeiden

Wenn aber Budget-Engpässe bestehen, müssen im Rahmen einer mittelfristigen IV-Planung Prioritäten gesetzt werden. Hier empfehle ich die Etablierung eines Anwenderausschusses, bestehend aus den Leitern der Fachbereiche, dem IV-Manager und dem Konzern-Controller, der nach für alle Beteiligte transparenten Priorisierungsregeln darüber befindet, welche Vorhaben zur Realisierung ausgewählt werden. Die Beteiligung des Konzern-Controllers ist hier besonders wichtig, um ihm einen "Quercheck" zwischen den Rationalisierungsversprechen der Bereichsleiter beim Ringen um die zur Verfügung stehenden Ressourcen einerseits und der späteren Realität nach Einführung der neuen Systeme andererseits zu ermöglichen. In der Holding gilt Entsprechendes je Profit-Center.

Wie bereits geschildert, können auch IV-interne Probleme zu erheblichen Schieflagen bei Anwendungsprojekten führen. Ich möchte dies am Beispiel der vermeintlichen Verantwortung des Projektleiters, wie man sie heute noch vielfach findet, aufzeigen.

Eine Software-Engineering-Abteilung schreibt ihm vor, welche Verfahren und Werkzeuge er einzusetzen hat. Die Abteilung Qualitätskontrolle prüft, ob alle Vorschriften eingehalten worden sind. Die Systemprogrammierung ist verantwortlich für das Datenbankdesign in der Phase des technischen Systementwurfs. Beim Datenbankadministrator muß er sich jede einzelne Felddefinition genehmigen lassen. Der Fachbereich überschüttet ihn ungeschützt mit Änderungs- und Erweiterungsforderungen. Und das Management gibt ihm Projektkosten und -termine vor.

Damit wird die Verantwortung des Projektleiters zur Karikatur. Daß Demotivation und permanente Reibungsverluste hier einen Projekterfolg unmöglich machen, braucht kaum noch hinzugefügt werden.

Zum Glück kommt dieses extreme Szenario nicht so häufig vor. Mit Abschwächungen findet man es aber in vielen Unternehmen. Wie es auch anders geht, zeigen auf dem Sektor der Anwendungsentwicklung erfolgreich operierende Unternehmen.

Natürlich kann man die Themen Phasenkonzept, Software-Engineering und Projektmanagement nicht in das Belieben jedes einzelnen Projektleiters legen. Ein einheitliches Konzept ist aus vielerlei Gründen unabdingbar. Hier kommt es aber darauf an, wie es entsteht und mit welcher Akzeptanzstrategie eine breite und sogar aktive Zustimmung bei den Entwicklern erreicht wird. Die meisten hierfür eingesetzten Stabsabteilungen für Methoden und Tools sind gescheitert. Sie wurden im Laufe der Zeit von den Entwicklern als "Schreibtischtäter" abgestempelt, die - fernab von der Praxis mit Kosten- und Termindruck - "abgehoben" hätten mit schulmeisterlichtheoretischen, für den praktischen Einsatz unbrauchbaren, Konzepten.

Stattdessen schlage ich vor, derartige Konzepte innerhalb einer Task Force zu entwickeln, deren Teilnehmer sich zu etwa einem Drittel ihrer Kapazität diesen Themen widmen und parallel dazu überwiegend in der praktischen Projektarbeit tätig bleiben. Diese sind dann auch die ersten, die ihr "eigenes Gift schlucken" - und zwar in der praktischen Projektarbeit -, bevor es nach deutlichen Erfolgen behutsam per Schneeballprinzip in andere Projektteams hineingetragen wird.

Projekte nach dem Schneeballprinzip verteilen

Auch die Qualitätskontrolle gehört in die Hand des Projektleiters. Sie wird von ihm nach einem einheitlichen, in der Task Force entwickelten, Verfahren durchgeführt und formal dokumentiert. Das Gleiche gilt für alle anderen Projekttätigkeiten. Dem Projektleiter ist es überlassen, ob er sich beispielsweise für spezielle Fragen des DB-Designs oder des TP-Monitors zusätzlich der Hilfe von Experten einer SE-Support-Gruppe bedient, die ebenfalls dem Leiter der Anwendungsentwicklung untersteht. Ist diese Gruppe genügend kompetent, wird er ihre beratende Hilfe gerne in Anspruch nehmen.

Eine zentrale Aufgabe des IV Managements besteht in diesem Zusammenhang darin, diesen Weg mit ihrer ganzen fachlichen und persönlichen Autorität zu fördern und zu unterstützen, "geeignete Männer der ersten Stunde" zu erkennen und bei ersten Erfolgen nicht einfach zur Tagesordnung überzugehen, sondern mittels gebührender Herausstellung - nach innen wie nach außen - solcher Leistungsfortschritte, Nachahmungseffekte bei den noch nicht so erfolgreichen Teams auszulösen.

Einen großen Motivations- und Leistungsschub kann auch die Ausgliederung des Dienstleistungsteils der IV haben. Richtig organisiert, bietet sie die Chance, sich von behindernden konzerninternen Restriktionen zu lösen, IV-Projekte wie am Markt operierende Unternehmen auf klarer Vertragsgrundlage mit höherer Disziplin auf beiden Seiten abzuwickeln, im Wettbewerb mit anderen Anbietern die Leistungsmotivation zu erhöhen und durch marktgerechte Bezahlung auch höhere Chancen bei der Beschaffung qualifizierten Personals zu haben.

Die sich daraus ergebende Möglichkeit zur Diversifikation soll jedoch nicht das Hauptziel sein. Zunächst kommt es darauf an, für das eigene Unternehmen ein deutliches Signal für die Veränderung verkrusteter Beziehungen der Zusammenarbeit zu setzen. Die Betätigung am Markt hat die zweite Priorität.