Projekte in der Krise V

Übernahme von externen Fremdprojekten

Nach einem interessanten Kommentar auf meinem letzten Artikel dieser Reihe nun also der versprochene Beitrag. Was ist zu beachten, wenn man ein Projekt übernimmt, dass vorher von einem anderen Dienstleister oder von der Fachseite betreut wurde. Für beide Fälle gibt es unterschiedliche Fallsticke, die ich nun einzeln beleuchten will.

Projekte eines externen Dienstleisters

Ohje. Schon beim ersten Überblick wird es klar. Die Dokumentation ist mangelhaft, veraltet oder schlicht gar nicht vorhanden. Anforderungen wurden zumeist per E-Mail gestellt und möglichst schnell abgehandelt. Getestet hat der Kunde auf Zuruf. Der letzte Dienstleister hat das Projekt gerade so und nur mit erheblichen Mehrkosten und Zeitverzug über die Bühne bringen können. Der Kunde ist bereits stinksauer und ahnt, was er für sein Geld bekommen hat. Dennoch ist er froh, dass das Projekt jetzt abgeschlossen ist und die Anwendung läuft. Jetzt, in der zweiten Phase soll die Performance erhöht und die Stabilität und Zuverlässigkeit gesteigert werden. Im Anschluss soll die Anwendung in den Managed Service übergehen, da es sich um ein kritisches Produkt handelt.

So oder so ähnlich kann sich ein Projekt darstellen, wenn der Anbieter gewechselt werden soll. Und direkt ist anzumerken „Vorsicht!“. Denn der Kunde wechselt den Anbieter bei einem Entwicklungsprojekt erst dann, wenn er wirkliche Schmerzen hat oder ihm schlicht kein anderer Weg bleibt. Das kann sein, weil die Kosten zu hoch waren, das Vertrauensverhältnis zerstört wurde, die Ziele meilenweit verfehlt wurden oder aber auch, weil beim Dienstleister zu viele Leute das Projekt oder die Firma verlassen haben und nun ohnehin die Expertise knapp wird.

Bei solchen Projekten ist also höchste Vorsicht geboten und man muss eine große Unsicherheit in Kauf nehmen. Eine große Unsicherheit bedeutet in unserem Business nun meistens leider erhöhte Risikoaufschläge und damit erhebliche Mehrkosten für den Auftraggeber. Noch dazu ist besonders das Managed Service Thema bei solchen Projekten ein gefährliches Pflaster, da es Service Level Agreements voraussetzt und damit meistens strenge Reaktionszeiten verbunden sind. Was passiert, wenn ein kritischer Fehler in der Anwendung nicht gefunden werden kann? Welche Vertragsstrafen werden dann für den Auftragnehmer fällig? Derartige Konstrukte können einen Auftrag schnell unwirtschaftlich werden lassen oder gar Verluste einbringen.

Der Umgang mit dem Kunden

Doch nun zum Wesentlichen. Wie gehe ich mit so einem Kunden um? Wie kann ich ihn für dieses Thema sensibilisieren, dass das Projekt leider eine größere Baustelle ist, als er gehofft hat? Eventuell werden dadurch schließlich auch seine (Jahres-)Ziele über den Haufen geschmissen und er muss sich vor höherer Stelle rechtfertigen.

Mir selbst ist einmal der Fehler unterlaufen, dass wir ein Projekt zu heftig und zu früh kritisiert haben. Auch wenn wir unsere Kritik mit konkreten Beispielen untermauern konnten, war dies dennoch ein Problem. Denn das Vertrauensverhältnis des Auftraggebers zu seinem letzten Dienstleister war über das Projekt zerrüttet und der Kunde entsprechend misstrauisch. Es gelang nur unter erheblichem eigenen Einsatz das Projekt doch noch zu retten. Das führte soweit, dass es zahlreiche größere und kleinere Hilfstools für das eigentliche Programm gab um Fehler wieder zu korrigieren oder zu überprüfen.

Nun kamen wir und bereits in den ersten Tagen sahen wir, welche Qualität das Programm hatte und das es quasi unwartbar war. Doch der Kunde fühlte sich davon angegriffen und war der Meinung, dass die Reaktion überzogen wurde um mehr Budget herauszuhandeln. Tatsächlich boten wir als erstes eine Refactoring-Phase an, die allein das bereitgestellte Budget für ein Jahr Support aufgebraucht hätte. Daraufhin bügelte der Kunde diesen Vorstoß ab und war künftig auch nicht mehr bereit Aufwände für Refactoring bereitzustellen. Doch was hätten wir anders machen können?

Die Möglichkeiten

Im Prinzip bleiben bei so einem Projekt dann nur 2 Möglichkeiten. Wenn man merkt, dass das Produkt nicht wartbar ist, sollte man gegebenenfalls die bisher investierten Aufwände – selbst wenn es Presales Aufwände waren – abschreiben und das Projekt ablehnen. Natürlich kann dies zur Folge haben, dass der Kunde einen dann auch nicht für weitere Projekte beauftragt. Daher ist das eine Frage der Abwägung.

Die zweite Möglichkeit erfordert mehr Fingerspitzengefühl und sollte nur in strategisch wichtigen Projekten versucht werden. Die Gefahr, dass das Projekt dennoch nicht erfolgreich ist, oder der Kunde sich querstellt sind relativ hoch und man sollte sich einen Fehlschlag leisten können. Es ist auch wichtig, dass dieses Bewusstsein sowohl bei den Beratern vor Ort als auch beim Management gegeben ist und man diesen Schritt wirklich gehen will. In diesem Fall kann man eine ausgedehnte Analysephase voranstellen, das Produkt sauber untersuchen und eine Risikobetrachtung durchführen. Jeder Punkt, der den Beratern auffällt muss sauber katalogisiert und bewertet werden. Wichtig sind aus meiner Sicht folgende Punkte:

Wahrscheinlichkeit – Wie hoch ist die Gefahr, dass das Risiko eintritt?
Auswirkungen – Wie groß sind die Auswirkungen für das Projekt?
Kosten – Wie groß sind die Kosten (z.B. Personentagen oder Euro) um das Problem zu beheben?

Jeder dieser Punkte bekommt nun eine Wertigkeit von 1-3, wobei eins für gering und drei für enorm stehen. Haben nun mindestens 2 Kriterien eine mittlere, oder ein Kriterium eine hohe Wertigkeit, dann sollte das Risiko detailliert bewertet werden. Das bedeutet:

  • Eine konkrete Beschreibung des Risikos
  • Beschreibung der Ursache
  • Beschreibung der Auswirkungen
  • Was kostet es, wenn wir das Risiko nicht beheben (in Form eines Risikoaufschlages)
  • Was kostet es, wenn wir das Risiko beseitigen (in Form von z.B. Refactoring)
  • Welche Auswirkungen hat das Risiko auf ein späteres SLA?
  • Ist das Risiko so groß, dass wir das Projekt deshalb nicht annehmen können, wenn es nicht beseitigt wird?

Das Ergebnis dieser detaillierten Betrachtung der Probleme gibt beiden Seiten eine objektive Verhandlungsgrundlage und man kann entscheiden wie man mit welchen Risiken umgeht. Die Lösungen können sein, dass man das Risiko trägt und Aufschläge verrechnet, dass man das Risiko beseitigt, oder auch, dass der Auftragnehmer das Risiko trägt und keine zusätzlichen Aufschläge dafür verrechnet. Auf jeden Fall hat man so eine managementtaugliche Betrachtung des Projektes, welches die Schmerzen des Auftragnehmers auch gut sichtbar macht.

Doch bedenkt bitte, dass selbst nach einer sehr aufwendigen Vorbetrachtung – unter umständen sogar als Teil des Angebots und damit unfaktoriert – es immer noch möglich sein muss aus dem Projekt auszusteigen. Es darf nicht sein, dass man sich mit dieser Betrachtung so hohe Kosten auf bürgt, dass man keine Möglichkeit mehr hat auszusteigen.

Tja, jetzt bin ich gerade mal bei der Hälfte und schon haben wir wieder 1000 Wörter zusammen. Daher wird der Umgang mit internen Projekten jetzt nun doch in den 6. Teil der Serie verschoben. Aber ich danke auf jeden Fall für die tolle Anregung! 🙂

Mehr zum Thema?

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s