Die unterschätzte Stellschraube: Vertragsart und Verbindlichkeit

Ein zweiter, häufig entscheidender Hebel ist die vertragliche Basis. Viele Probleme im Projektverlauf sind nicht nur „Verhaltensprobleme“ des Dienstleisters, sondern Systemeffekte der falschen Vertragsform.

Werkvertrag vs. Dienstvertrag

Beim Werkvertrag wird ein konkretes Ergebnis geschuldet. Idealerweise ist dieses Ergebnis in einem Pflichtenheft, einem Projektstrukturplan (PSP) oder klar beschriebenen Arbeitspaketen definiert. Die Schlussrechnung ist an die Abnahme geknüpft. Damit liegt der Dienstleister automatisch stärker unter Lieferdruck – er verdient sein Geld erst, wenn das „Werk“ geliefert und abgenommen ist.

Beim Dienstvertrag wird eine Leistung „nach bestem Wissen und Gewissen“ erbracht, typischerweise auf Basis von Zeit & Material. Es wird nicht garantiert, dass ein bestimmtes Ergebnis erreicht wird – bezahlt werden die eingesetzten Stunden, nicht die Erfüllung eines klar beschriebenen Lieferobjekts.

Das passt gut zu agilen Projekten, Forschung oder Vorstudien. Problematisch wird es, wenn Unternehmen sich aus Bequemlichkeit oder Zeitdruck vor einer sauberen Anforderungsdefinition drücken („Wir machen das agil, wir wissen ja noch gar nicht genau, was wir wollen“) – obwohl sie eigentlich ein eindeutig definierbares Ergebnis brauchen.

Dann entsteht eine Schieflage:

• Der Auftraggeber erwartet Ergebnisverantwortung.
• Der Vertrag gibt dem Dienstleister aber nur Aufwandspflichten.

Wenn dann noch interne Prioritäten beim Dienstleister wechseln, rutscht das Projekt schnell nach hinten. Schließlich läuft die Stundenuhr in anderen, lukrativeren Projekten genauso – während der Auftraggeber das Gefühl hat, „es passiert nichts“.

Konsequenz: Wer als Auftraggeber echte Verbindlichkeit und Lieferfähigkeit braucht, sollte prüfen, ob ein Werkvertrag mit klarer Leistungsbeschreibung nicht angemessener ist als ein reiner Dienstvertrag – auch wenn die Anforderungsanalyse am Anfang aufwendiger ist.

Innere Klarheit als Voraussetzung für äußere Steuerung

So bequem es wäre, die Verantwortung ausschließlich beim Dienstleister zu verorten: Projektleitungen haben selbst einen erheblichen Einfluss darauf, ob Verantwortung auf der anderen Seite überhaut übernommen werden kann.

Dafür braucht es innere Klarheit im Projekt – fachlich, strukturell und kommunikativ.

Klarheit über Inhalte und Ergebnisse

Je klarer das eigene Bild vom gewünschten Ergebnis, desto leichter lässt sich der Dienstleister steuern. Dazu gehören unter anderem:

• durchdachte Anforderungen (Pflichtenheft, Epics & User Stories mit Akzeptanzkriterien, klar benannte Lieferobjekte),
• ein grober, aber nachvollziehbarer Phasenplan,
• ein Projektstrukturplan, der zeigt, was geliefert wird und woraus sich Abnahmen ableiten lassen.

Ohne diese Klarheit wird das Projekt zur Projektionsfläche: Jede Partei versteht „Ergebnis“ ein bisschen anders – und entsprechend liefert man aneinander vorbei.

Klarheit über Zeit und Abhängigkeiten

Ein vernetzter Balkenplan oder Meilensteinplan schafft Transparenz:
Wer sieht, dass das Arbeitspaket eines Dienstleisters auf dem kritischen Pfad liegt und von dessen Terminlage der gesamte Go-live abhängt, versteht besser, warum Verzögerungen nicht „irgendwie zu verkraften“ sind, sondern unmittelbare Projektfolgen auslösen.

Für die Steuerung bedeutet das: statt vagen Appellen („wir brauchen das dringend“) kann mit konkreten Zusammenhängen argumentiert werden („wenn Sie hier zwei Wochen später liefern, verschiebt sich der Meilenstein X und damit der vertraglich vereinbarte Inbetriebnahmetermin“).

Klarheit über Kommunikation

Ein einfacher Kommunikationsplan hilft bereits enorm:

• Wer spricht mit wem, wie oft und mit welchem Ziel?
• Welche Formate haben wir (Jour fixe, Dailies, Lenkungskreis, Ad-hoc-Runden)?
• Welche Themen gehören in welches Gremium?

Gerade in angespannten Projektlagen ist eine regelmäßige, kurze Abstimmung (z. B. tägliches oder zweimal wöchentliches „Mini-Daily“) mit klarer Struktur oft wirksamer als sporadische, lange Krisenmeetings.

Steuerung und Eskalation: Wenn „nett fragen“ nicht mehr reicht

Auch mit guter Vorbereitung und klaren Strukturen kann es vorkommen, dass der Dienstleister nicht liefert. Dann geht es um aktive Steuerung und – wenn nötig – gezielte Eskalation.

Operative Steuerung stärken

Bevor man hart eskaliert, lohnt es sich, die operative Zusammenarbeit zu schärfen, zum Beispiel durch:

• klar protokollierte To-dos mit Verantwortlichem und Termin,
• verbindliche Reviews von Zwischenständen,
• frühe Tests von Teilfunktionen oder Prototypen,
• konsequentes Nachverfolgen von Zusagen.

Gerade bei agilen Setups ist es hilfreich, nicht alles „ins Backlog zu kippen“, sondern bei wichtigen Anforderungen genau zu verfolgen: Ist das Thema nur notiert – oder tatsächlich in einem Sprint verplant und umgesetzt?

Eskalationswege nutzen – intern und extern

Wenn operative Mittel erschöpft sind, wird Eskalation zur Pflichtaufgabe der Projektleitung, nicht zum persönlichen Versagen. Eskalation heißt nicht „sich beschweren“, sondern „das Problem auf die Ebene bringen, wo es gelöst werden kann“.

Es gibt mehrere Richtungen:

• vertikale Eskalation beim Dienstleister: Einbindung von Teamleitung, Bereichsleitung oder Geschäftsführung des Dienstleisters, wenn der operative Ansprechpartner nicht entscheiden oder priorisieren kann.
• interne Eskalation beim eigenen Management: Die eigene Führung muss verstehen, welche Konsequenzen ausbleibende Leistungen haben (Zeit, Kosten, Qualität, Risiken) – und ggf. politisch den Druck erhöhen oder Alternativen prüfen lassen.
• gemeinsame Eskalation: In manchen Fällen ist es hilfreich, den Kunden (bzw. die eigene Organisation) bewusst einzubeziehen und (kontrolliert) zu „beschweren“, um intern mehr Durchschlagkraft zu bekommen. Das setzt Vertrauen und ein gutes Standing voraus, kann aber sehr wirksam sein.

Wichtig ist, dass Eskalation sachlich, dokumentiert und lösungsorientiert erfolgt: Was war vereinbart? Was wurde (nicht) geliefert? Welche Folgen drohen? Welche Optionen gibt es (Nachbesserung, Teilabbruch, Neuvergabe, Anpassung des Scopes)?

Wenn das Projekt schon „an der Wand steht“: Deeskalation und Schadenbegrenzung

Manchmal sind Projekte so festgefahren, dass die Frage nicht mehr lautet: Wie ziehen wir das durch?, sondern: Wie begrenzen wir Schaden und Kosten?

Dann geht es um:

• ehrliche Bestandsaufnahme: Was ist tatsächlich fertig, was nicht? Was ist technisch nutzbar? Welche Abhängigkeiten gibt es zu anderen Projekten?
• Kosten-Nutzen-Abwägung: Lohnt sich eine konsequente Fertigstellung mit dem bestehenden Dienstleister noch – oder ist ein kontrollierter Abbruch bzw. Neustart mittelfristig günstiger?
• Deeskalation mit Blick nach vorn: Manchmal ist es sinnvoller, das Projekt bewusst zu beenden oder zu pausieren, statt mit hohem emotionalen und finanziellen Aufwand einen halbfertigen Zustand zu stabilisieren.

Auch das ist eine Form von Verantwortungsübernahme: Nicht krampfhaft weitermachen, nur weil man schon viel investiert hat, sondern bewusst entscheiden, welches Szenario mittel- und langfristig am wenigsten Schaden verursacht.

Eigene Verantwortung als Auftraggeber: besser aufsetzen, besser testen

So schmerzhaft es in der Rückschau manchmal ist: Fast jeder missglückte Dienstleisterauftrag offenbart Lernchancen auf Auftraggeberseite. Typische Ansatzpunkte dafür sind:

• Anforderungen ehrlich definieren: Nicht aus Bequemlichkeit auf eine klare Leistungsbeschreibung verzichten. Wenn das Ergebnis definierbar ist, sollte es auch definiert werden – und zwar so, dass es später als Abnahmegrundlage taugt.
• Dienstleister früh „testen“: Nicht erst im Go-live kritische Themen ausprobieren, sondern frühzeitig z. B. das Änderungsmanagement testen („Dieses Feature war nicht im ursprünglichen Scope – wie gehen wir damit um?“), Reaktionszeiten beobachten, erste Teilergebnisse abnehmen.
• Kompetenz und Rolle des Ansprechpartners prüfen: Ein paar gezielte Fragen („Wer macht bei Ihnen Projektleitung? Gibt es einen Phasenplan? Wie ist das Backlog strukturiert? Welche Jour-fixe-Struktur schlagen Sie vor?“) zeigen sehr schnell, ob gegenüber wirklich jemand mit Projektmanagement-Kompetenz sitzt – oder nur eine freundliche technische Fachkraft.
• Verantwortung aktiv wahrnehmen: Projektleitungen auf Auftraggeberseite sind nicht nur „Besteller“, sondern Gestalter des Systems: Sie schaffen Klarheit, setzen Prioritäten, organisieren Kommunikation, bringen Entscheidungen herbei und eskalieren, wenn nötig.

Fazit: Verantwortungsübernahme ist keine Einbahnstraße

Wenn der Dienstleister seinen Dienst nicht leistet, ist das ärgerlich, teuer und oft sehr frustrierend. Gleichzeitig ist es ein Anlass, Verantwortung im Projekt neu zu sortieren.

Verantwortung übernehmen heißt:

• beim Dienstleister zu klären, ob er kann, will, darf oder muss – und daraus passende Maßnahmen abzuleiten;
• die eigene vertragliche und strukturelle Ausgangslage realistisch zu betrachten;
• Eskalations- und Deeskalationswege bewusst zu nutzen;
• und vor allem: die eigene Rolle als Auftraggeber und Projektleitung aktiv wahrzunehmen.

Wer seine Projekte klarer, strukturierter und vertraglich sauberer aufsetzt, schafft ein Umfeld, in dem Dienstleister Verantwortung nicht nur haben, sondern sie viel wahrscheinlicher auch tatsächlich übernehmen können.