Lastenhefte: Zeit, die Reißleine zu ziehen

In unserer Digitalagentur erhalten wir noch immer Anfragen für beispielsweise Web-Relaunches, die auf einem Lastenheft beruhen. Unsere Erfahrung zeigt: Bereits die Erstellung des Lastenheftes hat beim Auftraggeber oft sehr viel Zeit gekostet. Das ist verlorene Zeit, die nicht in die Realisierung des Projekts gesteckt werden konnte. Außerdem sind in einem Lastenheft oft sehr detailliert Anforderungen beschrieben, die entweder völlig banal sind oder die – würde man sie genau wie beschrieben umsetzen – zu einem gewaltigen Aufwand führen würden. Der Nutzen fürs Projektmanagement ist also gering. Die Lösung sind agile Methoden. 

Ein Lastenheft ist ein Dokument, in dem ein Auftraggeber sehr detailliert beschreibt, welche Leistungen er von einem Auftragnehmer einkaufen möchte. Besonders bei Ausschreibungen (gern auch „Request for Proposal“ genannt) bzw. bei der Suche nach Dienstleistern und Lieferanten werden Lastenhefte eingesetzt, um auf der Grundlage eines ausführlichen Ausschreibungstextes verschiedene, vergleichbare Angebote zu erhalten. Als „Antwort“ auf das Lastenheft erstellen die Anbieter ein Pflichtenheft mitsamt Preiskalkulation. 
Was ein Lastenheft genau ist, ist noch nicht einmal eindeutig definiert. Laut Begriffsdefinition in der DIN 69901-5 enthält ein Lastenheft die Gesamtheit dessen, was ein Auftraggeber an Leistungen und Lieferungen im Rahmen eines Auftrags fordert. Der VDI ergänzt, dass eine Festlegung von Liefer- und Leistungsdatum klug wäre. Wie ein Lastenheft idealerweise aufgebaut sein sollte, ist natürlich auch nicht verbindlich geregelt. Deshalb werden meist Lastenheft-Vorlagen bzw. –Templates, oft als Word-Dokument, heruntergeladen und ohne große Anpassungen verwendet.
 

• Überblick: Was ist das Vorhaben, wer ist daran beteiligt, was sind Timing und Budget.
  → Der Auftraggeber erstellt ein Timing für ein extrem komplexes Projekt, dessen tatsächlichen Arbeitsaufwand er nicht einschätzen kann. Entweder erstellt man ein Timing und sieht danach, was in der Zeit bis dahin möglich ist. Oder man wünscht sich Funktionen und priorisiert, welche Funktionen in welchem Umfang sukzessive erstellt werden sollen.
• Ist-Situation: Wie ist die aktuelle Website aufgebaut (Technik, Inhalte, Probleme), welche Schnittstellen gibt zu anderen Systemen.
  → In diesem Punkt wird die alte Website durchanalysiert. Das ist im Grunde überflüssig, da die einzig relevante Frage ist: „Behalten oder wegwerfen“. 
• Soll-Zustand: Hier stehen die Anforderungen. Was sind die Ziele des Projekts? Was sind die genauen Aufgaben? Was soll das System können? Gibt es Ausbaustufen?
  → Hier lauern die meisten Fallen, denn der Soll-Zustand wird ohne Rücksprache mit dem Auftragnehmer festgelegt. Natürlich können Sie in den Soll-Zustand hineinschreiben „Wir wollen eine Suchfunktion, die exakt so gut wie die von Google ist.“ Aber das werden sie nicht bekommen. Denn das schaffen nicht mal die schärfsten Wettbewerber von Google. Das bedeutet: Sie benötigen eine realistische Einschätzung, was in welcher Zeit und mit welchem Budget möglich ist. Hinzu kommt, dass der Auftraggeber oft gar nicht die technischen Möglichkeiten kennt: Welche „Suchmaschine“ für die eigene Website hat denn das beste Verhältnis aus Einrichtungsaufwand, Funktionen und Nutzen? Im Rahmen einer offenen Diskussion ist das schnell geklärt, aber ohne genaue Analyse des Bedarfs und der Projektstruktur nahezu unmöglich. 
• Technik: Diese Technologien sollen eingesetzt werden. Manchmal werden veraltete Technologien oder exotische Systeme als „Pflicht“ gefordert. Aber wissen Sie wirklich zu 100%, welche Technik für Ihr Projekt optimal wäre?
  → Die Wahl der Technologien sollte mit den Dienstleistern besprochen werden, da diese die meiste Fachkenntnis besitzen. Seien Sie immer vorsichtig, wenn exotische Systeme vorgeschlagen werden. 

Nachdem das Lastenheft vom Auftraggeber erstellt wurde und zumeist nach einigen Abstimmungsschleifen verabschiedet wurde, wird in der Regel durch den Auftragnehmer ein Pflichtenheft erarbeitet. Laut DIN sollte das Pflichtenheft enthalten, mit welchen Arbeiten der Auftragnehmer den Auftrag realisieren will. Der VDI erklärt den Begriff so, dass im Pflichtenheft drinstehen sollte, wie alle Anforderungen des Lastenhefts realisiert werden. Erst nach Verabschiedung des Pflichtenhefts beginnt die eigentliche Umsetzungsarbeit! Sie sehen: Der Zeitraum vor dem eigentlichen Projektstart zieht sich unnötig in die Länge.

Ein Lastenheft gibt dem Auftraggeber das Gefühl, die volle Kontrolle über das Projekt zu haben. Nur: Das stimmt nicht. Denn der Auftraggeber hat in der Regel nicht die Fachkompetenz, um beispielsweise das Website-Projekt bis in jede Unwägbarkeit hinein zu durchdenken. Manchmal kann ein winziger, faktisch unbedeutender Extrawunsch für wochenlange Verzögerungen und Verteuerungen sorgen. Da nützt es Ihnen am Ende auch nichts, wenn Sie auf das ach so perfekte Lastenheft verweisen: Wenn im Projekt der Wurm drin ist, ist das Lastenheft nicht mehr viel wert. 

1. Das Lastenheft an sich frisst Zeit.

Ein Lastenheft schreibt sich nicht von selbst, im Gegenteil. Es dauert teilweise Monate, bis ein Lastenheft vom Auftraggeber erstellt, intern abgestimmt, überarbeitet und zum Schluss freigegeben wird. Diese Zeit wurde vergeudet, denn man hätte – mit agilen Methoden – schon längst mit der Umsetzung beginnen können. Unsere Erfahrung zeigt: ein zweitägiger Workshop ersetzt in der Regel das komplette Lastenheft. Das spart unfassbar viel Zeit. 

2. Das Lastenheft ist oft reine Innensicht:

Bei allen internen Diskussionen, die bei der Erstellung des Lastenheftes geführt werden, geht es meist um das eigene Unternehmen, sehr viel um Technik und ganz wenig um die echten Zielgruppen, nämlich die Nutzer. Das führt dazu, dass Funktionen „bestellt“ werden, die wenig Nutzen für z.B. Kunden und das Unternehmen haben. Die Folge ist, dass zu viel vom Budget in falsche Funktionen fließt, und dieses Geld fehlt am Ende für die wirklich wichtigen Dinge – die vielleicht gar nicht im Lastenheft drinstanden. Erfolgreiche Projekte sind konsequent an den Bedürfnissen der Nutzer ausgerichtet!

3. Das Lastenheft musste nicht durch einen Realitäts-Check.

Viele Leute wollen beim Lastenheft mitreden. Konsens ist wichtig. Also kommen viele fromme Wünsche hinein, und manchmal auch sehr teure Wünsche. Ob sich diese im Budget und im Timing umsetzen lassen, wird nicht geprüft. Wie auch. Diese Einschätzung muss dann der mögliche Auftragnehmer geben. Dabei stellt sich oft heraus, dass manche Wünsche nur durch (kleine) Änderungen umsetzbar werden. Dann beginnen die internen Abstimmungsprozesse wieder von vorne, da dieser spezielle Wunsch ja im von allen verabschiedeten Lastenheft drinstand… und das kostet schon wieder Zeit. Das lässt sich übrigens sehr einfach mit Workshops verhindern, bei denen der Dienstleister mit am Tisch sitzt und Wünsche direkt bewerten kann.

4. Fehler im Lastenheft werden teuer.

Der Aufwand für eine Schnittstelle wurde unterschätzt? Eine Anforderung wurde ein bisschen unscharf formuliert? Sie kennen es von großen Bauprojekten: Auftraggeber haben nicht das 100%ige Fachwissen zum Projekt – sonst könnten sie es ja selbst machen – und machen missverständliche Angaben im Lastenheft. Der Dienstleister nimmt das Geschriebene für bare Münze und kalkuliert entsprechend. Monate nach Projektstart stellt sich heraus: Oh, es gab ein Missverständnis. Und dann beginnt die Phase mit den gefürchteten „Nachträgen.“ 

5. Das Lastenheft bietet nur Scheinsicherheit.

Ein Lastenheft hat durch Form, Umfang und Entstehungsprozess den Status eines sakrosankten Plans, den nichts erschüttern kann. Dabei sorgt oft schon eine kleine Verzögerung am Anfang dafür, dass sich das Projektende um Monate hinauszieht. Das Lastenheft enthält nämlich keine Mechanismen, die einen zügigen Projektfortschritt ermöglichen. Außerdem: Im Projekt stellt sich bei der tatsächlichen Arbeit hin und wieder heraus, dass neue oder andere Funktionen für die Website nötig sind, weil seit der Erstellung des Lastenhefts viel Zeit ins Land gegangen ist. Und was passiert dann? Dann sagt der Dienstleister: „Kein Problem, aber das ist nicht im Scope. Hier ist der Nach-KVA …“ Die Lösung: Gestehen Sie sich ein, dass es im Laufe des Projekts Änderungen geben wird. Dann wird Flexibilität zum Teil des Projekts! Das geht natürlich nur mit agilen Methoden.

6. Eine Auftragsvergabe nach Lastenheft kennt keine Reißleine.

Die Dienstleister haben ihre Pflichtenhefte abgegeben. Der Dienstleister mit dem besten Angebot erhielt den Zuschlag. Nach einem halben Jahr im Projekt stellt sich heraus: Die Chemie stimmt nicht. Funktionen und Design entsprechen zwar rechtlich und technisch den Vorgaben, aber irgendwie fehlt das gewisse Etwas, beispielsweise weil die Webagentur wenig proaktiv ist. Sie würden gern das Projekt an dieser Stelle stoppen und an einen anderen Dienstleister vergeben. Geht aber nicht, weil der Vertrag über das Gesamtprojekt abgeschlossen wurde. Mit einer agilen Arbeitsweise, in der nur überschaubare „Sprints“ eingekauft werden, kann jederzeit die Reißleine gezogen werden.

7. Die Deadline gilt für das gesamte Projekt.

In einem Lastenheft wird in der Regel das Gesamtprojekt beschrieben. Der Dienstleister gibt dann ein Angebot für dieses Gesamtprojekt ab. Zum Tag X ist dann das Gesamtprojekt fertig. Und das ist ein Problem: Bei digitalen Projekten ist bei guter Planung eine nutzbare erste Version, z.B. ein MVP, oft bereits nach wenigen Wochen fertig. Diese Version kann bereits produktiv genutzt werden! Im klassischen Projektmanagement ist das nicht möglich. Außerdem funktioniert das mit den Deadlines sowieso so gut wie nie, weil in der Projektphase sowieso Extrawünsche aufkommen. Und dann sorgt gern ein einziger Extrawunsch dafür, dass sich das gesamte Projekt verzögert. 

8. Lebende Projekte leben.

In Jahr 1 werden die ersten Zeilen des Lastenhefts verfasst. In Jahr 2 wurde, nach langem Verfahren, ein Auftragnehmer gefunden. In Jahr 3 ist das Projekt kurz vor dem Abschluss. Allerdings hat sich in der Zeit die Welt weitergedreht. Wettbewerber haben vielleicht Gas gegeben und etwas Neues implementiert oder neue technische Möglichkeiten tun sich auf. Wurde das im Lastenheft berücksichtigt? Wohl kaum. Und so fließt viel Anstrengung in Technik, die vielleicht nicht mehr auf dem aktuellen Stand ist.

9. Billig rein, teuer raus.

Es gibt Dienstleister, die darauf spezialisiert sind, Ausschreibungen zu gewinnen. Sie haben die Fähigkeit, wie Bluthunde Ungenauigkeiten im Lastenheft aufzuspüren. Diese Ungenauigkeiten werden dann 100% korrekt im Wortsinne zur Kalkulationsgrundlage. Nur: Mit gesundem Menschenverstand ist klar, dass der Auftraggeber eigentlich etwas komplexeres gemeint hat und nur etwas unscharf formulierte.
Ein Beispiel: „Interessenten sollen sich mittels eines Formulars für Veranstaltungen an- und abmelden können.“ Der gewiefte Auftragnehmer liest heraus, dass ein E-Mail-Formular genügt, deshalb kann es günstig angeboten werden. Im Pflichtenheft ist das nur ein Punkt von vielen, das fällt nicht auf. Was der Auftraggeber aber eigentlich wünscht, ist ein echtes Buchungstool für Veranstaltungen, das später um eine Bezahlfunktion erweitert werden könnte.
Was passiert in der Ausschreibung? Der Minimalanbieter bietet den besten Preis, erhält den Zuschlag und im Laufe des Projekts dämmert dann dem Auftraggeber, dass er nur ein reines E-Mail-Formular gekauft hat. Das „große“ Buchungstool baut der Auftragnehmer gern auf, aber zu Zusatzkosten. Wäre das Projekt mit einem Workshop gestartet, wäre das sofort aufgefallen.

Es gibt eine Möglichkeit, digitale Projekte im Rahmen des Timings und im Budget so zu realisieren, dass das Endergebnis begeisternd wird. Gleichzeitig sind erste Ergebnisse oft bereits wenige Wochen nach Projektstart sichtbar und nutzbar. Oder anders gesagt: In der Zeit, in der Ihre Wettbewerber sich noch mit Lastenheften und Pflichtenheften beschäftigen, sind Sie vielleicht schon längst online. Zu geringen Kosten und mit mehr Leistungsumfang. Wie das geht? Mit einem Workshop als Vorbereitung und mit agilen Methoden (z.B. Scrum). Und wenn Sie fragen: Ist unsere Organisation bereit für Scrum? Ja, das ist sie – wenn Sie die Erfahrung gemacht haben, dass Projekte mit herkömmlichen Methoden länger dauern, teurer werden als gedacht oder komplett scheitern. Lesen Sie dazu das Scrum-Whitepaper.

Schritt 1: Ein Workshop

Am Ende entscheiden auch immer Kosten über die Auftragsvergabe, aber es wird unterschätzt, wie gut man mit einem Dienstleister zusammenarbeiten kann. Mit einem Workshop, gemeinsam mit der Digitalagentur, verkürzen Sie Prozesse um mehrere Wochen und bekommen ein Gefühl für Charakter und Leistungsbereitschaft der Digitalagentur. Bei einem initialen Workshop (Lesetipp: Whitepaper zu Workshops) erarbeiten die Projektverantwortlichen und Entscheider auf Ihrer Seite gemeinsam mit Experten der Agentur beispielsweise, was die neue Website leisten muss und welche internen und externen Abhängigkeiten bestehen. Die Agentur-Experten können sofort Einschätzungen abgeben, welche Funktionen welchen Aufwand bedeuten. Es ist immer wieder erstaunlich, wie schnell sich anscheinend große Probleme komplett in Luft auflösen, und wie in der Diskussion die wirklich kritischen Punkte herausgearbeitet werden. Nach dem Workshop, beispielsweise an 2 Tagen, kann das Projekt im Prinzip schon mit dem ersten Sprint starten.

Schritt 2 bis X: Sprints

Lassen Sie zu, dass sich Umfang und Ergebnis des Projekts laufend ändern können. Sprints, das sind in der Sprache der agilen Projektmanagement-Welt konzentrierte Projektphasen von rund 2 Wochen Länge, eignen sich dafür hervorragend. So funktioniert’s: Sie geben Anforderungen in Form von „User Stories“ vor, wie beispielsweise „User sollen auf der Website Seminare buchen können“. Anschließend priorisieren Sie die User Stories in einer Art Liste (Backlog). Anschließend sagt die Agentur, was sie in diesem Sprint schaffen wird – und zwar als nutzbare Funktion, nicht nur als Designvorschlag. Nach dem Sprint wird evaluiert: Häkchen dran? Optimierungen nötig und wichtig? Und im nächsten Sprint sind dann schon die nächsten Funktionen dran. Im Idealfall sind so die wichtigsten Teile der Website so schnell fertig, dass man sie zügig launchen kann. Da sich niemand mit Nice-to-have-Funktionen verzettelt, wird Zeit- und Geldverschwendung im Keim erstickt. Und das alles ohne Lastenheft. Gerade weil es eben kein Lastenheft gibt. 

Sie planen ein Projekt, bei dem Sie ein Lastenheft vermeiden möchten, zugunsten einer agilen, ergebnisorientierten Arbeitsweise? Fragen Sie bei uns einen Workshop an, um die Projektbeschreibung oder die Ausschreibung perfekt zu gestalten.

Wenn Sie also das nächste Mal ein Lastenheft erstellen wollen oder sollen: Lassen Sie es sein und nutzen Sie stattdessen agile Methoden.