Was vor Projektvergabe zu bedenken ist

08.06.2005
Von Dr. Christoph

Es ist wenig effizient, einen perfekten Anforderungskatalog zu definieren und dann am grünen Tisch den Grad zu bestimmen, in dem Standardprogramme diesen erfüllen sollen. Vieles lässt sich besser am konkreten Objekt (Standardprogramm) klären, und das in einem Geben und Nehmen. Das heißt, dass der Auftraggeber bei einigen Anforderungen Abstriche macht und dafür eine organisatorisch gute und kostengünstige Lösung bekommt.

Voraussetzung dafür ist, dass er aus dem Projekt aussteigen kann, sollte die Standardsoftware doch nicht passen oder der Auftragnehmer nicht leistungsfähig genug sein. Daher ist es ratsam, sich im Vertrag das Recht eines Rücktritts ohne Angabe von Gründen einräumen zu lassen und nur die bis dahin bereits in Anspruch genommenen Dienstleistungen bezahlen zu müssen.

Damit diszipliniert sich der Auftraggeber selbst, bei der Projektdurchführung von vornherein darauf zu achten, ob er eine taugliche Lösung eingekauft hat, um seine Kosten im Rücktrittsfall gering zu halten. Aber auch der Auftragnehmer erkennt so, dass er sich besonders bemühen muss, seinen Kunden zu halten.

Auf dieser Basis sind bei Vertragsabschluss auch Zirkapreise akzeptabel, die nach Abschluss der Analysephase in Festpreise umgewandelt werden sollen. Bei dieser Konstellation wird der Auftragnehmer die Kirche im Dorf lassen. Das Organisationsprojekt ernst nehmen.

Der Auftragnehmer übernimmt die Aufgabe, die Software einzuführen. Es bleibt aber die Aufgabe des Aufraggebers, die Organisation zu schaffen, in der er die Software nutzen will - soweit er das nicht ausdrücklich dem Auftragnehmer überträgt. Zwar ist dies den meisten Auftraggebern bewusst, dennoch vernachlässigen viele ihr Organisationsprojekt. Angebote im Wettbewerb einholen.

Wichtig ist, dass die Anforderungen schriftlich und dort detailliert spezifiziert sind, wo Besonderheiten vorliegen. Wer Funktionen, die sich unterschiedlich realisieren lassen, nur stichwortartig beschreibt, hat später keinen Anspruch auf die tatsächlich benötigte Realisierung, sondern lediglich auf eine von vielen möglichen.