Am Anfang jedes Softwareprojekts steht ein Anforderungsdokument, in dem der Kunde beschreibt, welche Anforderungen er an die neue Software hat. Dafür gibt es bekanntlich verschiedene Möglichkeiten und Detaillierungsgrade, es kann sich um allgemeine Festlegungen zu den Geschäftszielen handeln, die mit der Software erreicht werden sollen, aber auch um genaue Beschreibungen, welche Funktionen die Software haben soll und wie diese aussehen und sich verhalten sollen.
In jedem Fall stellt sich die Frage, wie weit der Anbieter in die fachlichen Details und Geschäftsprozesse des Kunden eindringen sollte. Häufig sagt man, dass es gut und sogar notwendig ist, dass der Softwaredesigner, vielleicht sogar der Entwickler, die betroffenen Vorgänge beim Kunden versteht und seine Ziele, die letztlich die Erfolgskriterien des Projekte sind, nachvollziehen kann. Aber ist das wirklich immer nötig? Und anders herum: reicht das immer aus?
Versteht der Entwickler viel von den Verfahren und Prozessen des Kunden, hat er etwa Branchen-Know-How, dann birgt das durchaus auch Gefahren. Häufig vermutet der Kunde, dass er Details nicht mehr erklären muss, und auch der Entwickler glaubt nach wenigen Hinweisen schon, dass „alles klar“ ist. Auf dieses Weise kann es in Details zu Flüchtigkeitsfehlern kommen, die erst im produktiven Betrieb bemerkt werden.
Eine klare Aufgabentrennung, in der der Kunde ein Anforderungsdokument zu erstellen hat, das es nicht erfordert, dass der Entwickler sich überhaupt mit der Fachlichkeit beschäftigt, scheint dann die Lösung zu sein. Allerdings entstehen auf diese Weise selten optimale Lösungen. Die Vorstellungen, die sich der Kunde von der Software macht, sind manches Mal nur mit viel Aufwand umsetzbar, auf der anderen Seite kann der Entwickler aus anderen Projekterfahrungen heraus Lösungen anregen, auf die der Kunde gar nicht kommt. In so einem Moment wird der Entwicklungspartner zum Berater.
Damit eine solche Partnerschaft gelingt, muss sie allerdings richtig strukturiert werden, und auch die Entscheidungs- Verantwortung muss klar definiert sein. Insbesondere muss vertraglich klar geregelt sein, wie sich die Ergebnisse der Beratung auf die Definition der Erfolgskriterien und auf das Projektbudget auswirken, sonst sagen die Projektbeteiligten am Ende: „Die Zusammenarbeit war sehr schön, und wir haben uns gut verstanden – leider ist das Projekt nicht zu einem erfolgreichen Ende gekommen…“