Wieviel Pflichten- / Lastenheften macht Sinn?

Diese Woche hatte ich wieder einmal ein Newsletter vom ERP – Hersteller Oxaion in meiner Inbox. Die folgenden Zeilen daraus führten dazu, dass ich den Newsletter etwas genauer anschaute: 

„Projektstrukturen in Unternehmen werden zunehmend agiler, dementsprechend werden auch Softwareprojekte immer agiler, sprich inkrementell und iterativ umgesetzt. Da erscheint ein starr geführtes Lastenheft erstmal wie ein Relikt aus einer anderen Zeit. Doch gerade für mittelständische Unternehmen ist die Einführung einer Unternehmenslösung nach wie vor ein komplexes Projekt, das Kapital, Zeit und Personal bindet. Da kann sich eine „Ach fangen-wir-einfach-mal-an“-Mentalität
schnell rächen. Deshalb gilt auch in Zeiten des agilen Projektmanagements: Ein gut geführtes Lastenheft erleichtert die Suche nach dem passenden Anbieter und dient später als Grundlage für eine erfolgreiche Zusammenarbeit.“

Das tönt spannend, also hab ich mir den Blogeintrag von Oxiaon im Detail angeschaut.

Wenn ich Oxaion richtig interpretiere, so gehen die davon aus, dass ein Lastenheft für ein Projekt umfangreich definiert sein muss. Auch wenn die Lösung nachher agil oder iterativ umgesetzt wird. Es ist die Rede von schnell einmal 2500 Kriterien die aufgelistet werden und das ein unabhängiger Berater von Nutzen sein kann.

In meiner beruflichen Laufbahn habe ich auf Anbieterseite sehr viele solcher Lastenhefter beantwortet. Kam es zum Projekt, so konnte man diese Lastenhefter jedoch selten übernehmen. Die Differenz zwischen dem was der Anbieter, und dem was der Nutzer in die einzelnen Punkte interpretierte war schlicht zu gross. Oder das Lastenheft basierte auf Ideen und Ereignissen, welche nicht mehr aktuell waren. Oder die Software hatte im Standard eine bessere Lösung als im Lastenheft definiert. Oder die im Lastenheft dokumentierten Prozesse waren auf einer Flughöhe definiert, dass diese für die Software nicht geeignet sind. Oder, oder, oder…. – Was macht man in solchen Fällen? Die schlechtere, veraltete Lösung umsetzen weil es im Lastenheft steht? Ein Change Request? Mit dem Standard arbeiten und dann schauen wie es läuft? Zuerst ein Einsatzkonzept und danach dieses umsetzen – egal was im Lastenheft stand? Viele Ansätze hab ich schon gesehen, dass ein Pflichten, resp. Lastenheft jedoch 1:1 umgesetzt wurde, hab ich nie erlebt.

Ich begleite aktuell ein Evaluations-Projekt. Wir haben uns dabei für einen neuen vereinfachten Lösungsansatz entschieden, den ich hier gerne etwas ausführen
möchte.

In einem ersten Schritt haben wir Muss-Kriterien definiert. Das waren weniger als zehn Kriterien (z.B. Branchenreferenzen, Referenzprojekte, Anzahl Mitarbeiter) die ein
Anbieter erfüllen muss, um überhaupt in Frage zu kommen.

Danach haben wir einige Prozesse definiert, die wir ihn von diesen Anbietern sehen wollten. Die Prozesse wurden gewichtet und ein Bewertungsraster erstellt.

Jeder Anbieter konnte daraufhin seine Lösung mit den von uns definierten Prozessen in einem halben Tag vorstellen. Aufgrund dieser Vorstellungsrunde sind wir mit den besten drei Anbietern in die Detailworkshops gegangen. Wir definierten unsere Prozesse, die wir von den Anbietern gezeigt haben wollten. Daraufhin konnten die Anbieter vor Ort kommen, um ihre Fragen zu klären, den Betrieb kennenzulernen und anschliessend einen Prototyp zu bauen. – Auch hier wurden Bewertungsbögen wurden erstellt und die Lösungen miteinander verglichen.

Bewusst verzichtet haben wir dabei auf ein detailliertes Lastenheft. Wir wollten die Prozesse sehen um festzustellen, ob der Anbieter den Kunden auch versteht
und wie die Zusammenarbeit zwischen den Parteien funktioniert. Im Blogeintrag von Oxaion wird dann darauf eingegangen, dass das die Einführung mit agilen Schritten vorwärts kommt. Wir sind auch von einem solchen Ansatz ausgegangen und haben uns deshalb auf die Prozesse und das Tagesgeschäft fokussiert.

Die Evaluation läuft noch, aber wir sind zuversichtlich, dass wir so den besten Partner für unser Projekt finden. Ob es die Lösung mit den besten Features ist, weiss ich nicht. Aber mit dem richtigen Partner können die Herausforderung im Projekt umgesetzt werden. Ich unterstütze deshalb ein Punkt aus dem Blogeintrag von Oxaion voll und ganz: „FAZIT: Wichtig ist somit neben einer guten funktionalen Lösung ein vertrauensvolles Verhältnis zum ERP-Anbieter. Das erleichtert nicht nur die Erstellung des Lastenhefts sondern hält auch den Projekt- und Kostenaufwand überschaubar.

Wenn die Zusammenarbeit mit dem Anbieter nicht klappt, so kann das Lastenheft oder die Lösung noch so gut sein. Es wird nicht gut funktionieren.

Um den Bogen zum Newsletter zu machen: Ich sage nicht, dass man ein „fangen-wir-einfach-mal-an“ Projekt starten soll. Ich behaupte aber, dass eine Liste mit unzähligen Kriterien nicht zielführend ist. Und by the way: Eine agile Vorgehensmethodik hat nichts mit „Ach fangen-wir-einfach-mal-an“ zu tun.

Was sind Eure Erfahrungen mit Lastenhefter? Wie detailliert sollen diese sein? Macht es Sinn jede Funktion im Vorfeld zu definieren und festzuhalten?

Werbeanzeigen