Die Annahme, dass die outputbasierten Anforderungen im Voraus vorhergesagt werden können, beruht auf zwei weiteren Annahmen. Zum einen, dass die outputbasierten Anforderungen sowohl vom Kunden als auch vom Lieferanten vollständig verstanden werden und zum anderen, dass die Software fertig gestellt werden kann, bevor wesentliche Änderungen auftreten. Mit anderen Worten, um optimal zu funktionieren, verlangt das Vertragsmodell von beiden Vertragsparteien, über perfekte Informationen zu verfügen. Das ist praktisch unmöglich. Auf den ersten Blick und für jeden, der nicht direkt an der Umsetzung des IT-Projekts beteiligt ist, mag das Vertragsmodell äußerst sinnvoll erscheinen. Es schafft ein Gefühl von Sicherheit und Vorhersehbarkeit in Bezug auf das IT-Projekt und bietet eine klare und verständliche Struktur für die verschiedenen Aktivitäten, die am IT-Projekt beteiligt sind. Außerdem spiegelt es aktuelle Beschaffungsmodelle wider. Ich möchte einige Bemerkungen machen. Die Unfähigkeit eines Kunden, Bedürfnisse zu identifizieren, im Gegensatz zu Denkmitteln, ist etwas, das ich regelmäßig als praktizierendes PM/BA begegne, und ich stimme den Autoren zu, dass eine häufige frühe Manifestation dieser Anforderungen der schlecht durchdachte Business Case ist, der in der Regel durch einen ineffektiven Überprüfungsprozess begünstigt wird.
Ein Projekt, dem es an einer glaubwürdigen zugrunde liegenden Erzählung im Business Case fehlt, macht eine effektive Projektführung nahezu unmöglich, unabhängig von der Entwicklungsmethodik. Ich weiß nicht, warum wir trotz der Bände, die darüber geschrieben wurden, weiterhin Projekte initiieren, die auf fehlerhaften Geschäftsfällen basieren. Ist es Hybris? Unwissenheit? Wie die Autoren feststellen, ist die Vorbereitung detaillierterer Anforderungen durch einen kompetenten Wirtschaftsanalytiker oft das erste Mal, dass die Stakeholder die Möglichkeit haben, einen effektiven Einblick in das Geschäftsproblem und die Art einer geeigneten Lösung zu erhalten. Bei der Anforderungsdefinition wird viel gelernt, das zur Klärung und/oder Überarbeitung der ursprünglichen übergeordneten Anforderungen und des allgemeinen Business Case verwendet werden kann. Leider wird dieser wichtige Prozess oft dadurch vereitelt, dass der Wirtschaftsanalytiker nicht unabhängig vom Entwickler ist oder nicht in der Lage ist, die Analyse ordnungsgemäß durchzuführen, weil die stur empfundene Notwendigkeit besteht, “mit der wirklichen Arbeit fortzustehen” (ich höre das immer noch) oder Druck, die Managementerwartungen nicht zu stören. Viele dieser Probleme können dadurch angegangen werden, dass die Geschäftsleitung die technische Entwicklungsphase getrennt von der Definitionsphase für Anforderungen genehmigt, sofern der Geschäftsfall weiterhin tragfähig ist. Der Abschnitt zum Scheitern des Geschäftsmodells unterstreicht, wie wichtig es ist, anzuerkennen, dass die Softwareimplementierung von organisatorischen Prozessänderungen einschließlich Prozessumengineering begleitet werden muss. Das Management dieser Veränderung ist eine der Aufgaben, von denen sich it-Praktiker und erfahrene Projektträger besser ausrichten.