Nach wie vor werden im Entwicklungsprozess die fachlichen Anforderungen nicht systematisch strukturiert und zu wenig auf Richtigkeit, Widersprüchlichkeit, Vollständigkeit und Wirtschaftlichkeit überprüft. Die Beschreibungen sind sprachlich nicht eindeutig und lassen viel Spielraum für Interpretationen. Selbst adäquate Mittel wie UML-Diagramme dienen oft nur als Word-Ersatz. Der Entwickler setzt die qualitativ unzureichenden Artefakte in Codierung um und interpretiert sie zwangsläufig nach seinem Wissen. Anders als im Brückenbau, in dem detaillierte Planungen den Ausführenden wenig Spielraum für Interpretationen lassen, liegt hier in der Softwareentwicklung eine Bruchstelle.

Zudem fehlen die Instrumente, Anforderungsänderungen in die Entwicklung zu übertragen. Sattdessen werden gewünschte Modifikationen verteilt in Protokollen, E-Mails und Request-Tracking-Tools beschrieben oder gleich im Code nachgezogen. Bei Tests und in der Abnahme ist dann nicht mehr klar, was eigentlich getestet werden muss und welche finalen Entscheidungen zur Funktionsweise des Systems getroffen wurden.

Die Arbeit der Entwickler lässt sich kaum kontrollieren

Damit wird die Bewertung des Projektfortschritts zum Problem. Zwischen dem Wissen in den Köpfen einzelner Fachexperten und dem Code gibt es keine Zwischenstufe, keine Abstraktionsebene, die dabei helfen könnte, die Arbeit der Entwickler zu beurteilen und notfalls korrigierend einzugreifen. Die Unsicherheit manifestiert sich in überdimensioniertem Projekt-Controlling, das nur scheinbar den Projektstatus widerspiegelt. Das Qualitätsmerkmal "Risiko" gerät außer Kontrolle.

Schließlich ist der Softwarebetreiber abhängig von Fachexperten und Entwicklern, die als Einzige die Zusammenhänge verstehen. "Never touch a running system" ist dann der in der Branche wohlbekannte Endstatus des Systems. Keine befriedigende Lösung, wenn das Unternehmen auf neue Herausforderungen reagieren muss.