Projektverzögerung

Zur Zeit arbeite ich in einem Projekt, das bereits über ein Jahr Verzug hat. Es geht um die Migration einer Eigenentwicklung auf ein Kaufprodukt. In den  Datenbanken sind umfangreiche Daten enthalten. Unser Objektmodell ist relativ einfach gestrickt. Allerdings ist dadurch das System mit vielen „versteckten“ Sonderlösungen bespickt.

Das Modell der Kaufsoftware unterscheidet sich stark von dem aktuellen, die Technologie der Umsetzung ist eine andere, die Anpassungen an unsere Abläufe gestalten sich schwieriger als geplant, usw. usf.

Nun hat sich unser (höheres) Management das Ziel gesetzt, die Migration auf jeden Fall bis zum Geschäftsjahresende durchzuziehen.

Wir haben mehrfach darauf hingewiesen, das der Zeitplan unter den gegebenen Voraussetzungen nicht zu halten ist.

Wir haben zu wenig Mitarbeiter. Aber selbst wenn wir jetzt noch weitere Mitarbeiter hinzubekämen, würde das nichts bringen, denn die Aufgaben erfordern detailierte Kenntnisse von unserem vorhandenen System und der Technologien, die das System beschreibt. Mit anderen Worten: eine Einarbeitung würde viel zu lange dauern.

Optionen, wie Umfang reduzieren oder abändern oder eine andere Auslieferungsstrategie wählen, werden vom Projektmanager bisher nicht wirklich verfolgt.

Mein Angebote, bei der Erstellung von Entsccheidungsvorlagen für das Management zu helfen, werden nicht angenommen.

Ich kann diese Entscheidungshilfen auch nicht nebenbei alleine erstellen, da ich, wie alle Projektbeteiligten, zu mehr als 100% verplant bin.  Nein, ich übertreibe nicht! Eine unzureichende Resourcenplanung rächt sich.

Wie kann man die Kollegen überzeugen, daß es Sinn macht die fachliche Arbeit vorübergehend einzustellen und erstmal eine neue Strategie zu erarbeiten?

Als ich erstmals meine  Gedanken bezüglich Reduzierung des Umfanges bei einer Projektbesprechung meinen Kollegen mitteilte, hagelte es Kritik.

„Das können wir den Anwender nicht zumuten.“ ,
„So eine Reduzierung entscheide ich nicht.“,
„Dann wird die Anpassung xy nie umgesetzt.“…

Natürlich kann man dem Anwender nicht zumuten ein unangepasstes System vor die Nase gesetzt zu bekommen, aber es muss ja nicht heissen, das dies so bleiben muss. Wenn ein Ziel im Projekt lautet am x.x.2011 auszuliefern, heist es nicht das das Projekt dann beendet ist. Das mag keine schöne Lösung sein, aber es ist eine, die den Zielen entspricht.

Aber auch der Hersteller ist in Sachen Projektplanung nicht wirklich überzeugend. Ich erinnere mich ein eine Diskussion, als wir am Rande einer Besprechung einforderten, die einzelnen aus Herstellersicht erforderlichen Arbeitspakete inklusive Paketabhängigkeiten genannt zu bekommen, damit wir eine interne Planung aufsetzen können, wurde mit der aus meiner Sicht auf inkompetenz deutende Gegenfrage „…, sagt mir erst bis wann ihr was liefern könnt.“ beantwortet.

Eigentlich sollten wir erstmal die Anwendungsfälle dokumentieren, dann über eine Umsetzung im Zielsystem diskutieren und nach anschliessender Definition die Auswirkungen auf das Modell und die Migration der Daten behandeln. Um Abhängigkeiten zwischen den Paketen in Einklang zu bringen, müsste im Anschluss über alles konsolidiert werden. Der Hersteller drängt aber darauf, daß wir z.B. erst Antworten für die Datenmigration liefern.

Ich habe den Eindruck, das der Hersteller eine solche strukturierte Vorgehensweise deswegen untergräbt, um immer im Nachinein eine Möglichkeit zu haben, uns den Schwarzen Peter zuzuschieben:

„Ihr habt nicht pünktlich geliefert.“,
„Das ist eine neue Anforderung.“, …

Schreibe einen Kommentar

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 )

Google+ Foto

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

Verbinde mit %s