Die Moral eines Fehlschlages //2066

Aus verlässlicher Quelle habe ich die folgende Angelegenheit erfahren, die ich aus gewissen, nicht näher erläuterbaren Gründen im Blog festhalten möchte.

Ein größeres Unternehmen (bei dem mein Informant angestellt ist) muss regelmäßig gesetzlichen Prüf- und Dokumentationsaufgaben nachkommen. Ein (geübter) Mensch würde dafür mindestens einen Tag brauchen. Also liegt die Idee an eine Software nah, die die Routineanteile dieser Pflichten übernimmt. Dann könnte der Aufwand auf ein bis zwei Stunden reduziert werden.
In der Tat existiert dazu bereits seit zwanzig Jahren oder so eine derartige Software. Die wurde allerdings nie richtig angenommen, weil sie nicht wirklich funktioniert. Keine intuitive Eingabe, fehlerträchtig, häufige Abstürze, und dann sind alle bisher erhobenen Daten weg, etc.. Das GUI ist auch längst nicht mehr zeitgemäß. Die gesetzlichen Auflagen wurden seither erweitert, aber das Programm ist mittlerweile nicht mehr wartbar, da der wichtigste Entwickler inzwischen in Rente ist und seine Sourcen weder dokumentiert noch versioniert hat.

Also entschlossen sich die Verantwortlichen nach einigem Hin und Her vor ein paar Jahren, einer kleinen Softwarefirma als Subunternehmen den Auftrag zu geben, ein Programm dafür neu aufzusetzen. (Ich war damals auch im Gespräch, aber lehnte ab – zu verworrene Anforderungen und auch eine Nummer zu groß für einen Einzelkämpfer, zumal es mit meinem sonstigen Fachgebiet überhaupt keine Berührungspunkte gab.)
Das Projekt verzögerte sich noch, aber inzwischen hätte es eigentlich abgeschlossen sein sollen.
Nun wurde ein Prototyp vorgelegt, bei dem jetzt schon absehbar ist, dass er nicht funktionieren wird. Wichtige Konfigurationsmöglichkeiten fehlen.
Das Budget ist längst erschöpft. Momentan ist es offen, wie es weitergeht.

Mein Informant (der ein wichtiger Anwender ist, und auch andere Anwender einlernt und instruiert), ist verärgert, weil er überhaupt nicht in den Entwicklungsprozess eingebunden worden ist. Er hatte nie Einladungen zu Projekttreffen erhalten, und befürchtet jetzt, für das Scheitern mitverantwortlich gemacht zu werden.

Die alte Software funktioniert nicht richtig und ist nicht mehr auf dem aktuellen Stand.
Die neue Software funktioniert erst recht nicht.
Geld für eine Neuentwicklung ist nicht mehr vorgesehen.
So kann man ein wichtiges Projekt in den Sand setzen. Immerhin ein Beispiel, aus dem man lernen kann, wie man es nicht machen soll.

Wer beabsichtigt, ein Projekt outzusourcen, sollte wenigstens einen Festpreis vereinbaren, um zumindest einige Risiken zu vermeiden. Wer als Auftragnehmer zuversichtlich ist, das Projekt innerhalb eines vernünftigen Zeitrahmens erledigen zu können, sollte doch eigentlich kein Problem haben, dafür einen Festpreis zu veranschlagen.