Bei einem meiner Kunden gibt es ein größeres Implementierungsprojekt, bei dem es bereits seit vielen Monaten üblich ist, den Betrieb des sich in der Pilotphase befindlichen Software-Systems durch Projektmitarbeiter unterstützen zu lassen. Projektmitarbeiter (Entwickler, Tester, Software-Architekten) sitzen also während der Produktion bei den betrieblichen Mitarbeitern und übernehmen selbst teilweise die Rolle der Operators. Das hat viele gute Gründe, z.B.
- Noch nicht alle betrieblichen Mitarbeiter sind umfassend in der Nutzung des neuen Systems geschult. Das war tatsächlich der Auslöser für dieses Vorgehen.
- Das neue System erfordert auch neue Rollen im Betrieb. Die Definition der Rollen, die Vereinbarungen dazu mit der Arbeitnehmervertretung und die Besetzung der Rollen sind noch nicht komplett vollzogen.
- Das neue System hat noch schwerwiegende Fehler, deren Erkennung, Analyse und Umgehung von den Projektmitarbeitern optimal durchgeführt werden kann.
- Die Fehlermeldungen sind aussagekräftiger. Unnötige Rückfragen werden vermieden.
- Die Sensitivität der Entwickler für produktionskritische Fehler wird geschärft. Die fälschliche Ablehnung von Fehlern wird reduziert.
Das ist alles gut und schön, birgt aber die große Gefahr eines Never-Ending-Projects. Projekte neigen sowieso dazu, für ihren eigenen Lebensunterhalt zu sorgen. Wenn dem Betrieb nun noch auf dem Silbertablett die kostenlose Unterstützung durch „Experten“ serviert wird, gibt es kaum noch Motivation, sich selbst und alleine auf das neue und ungewohnte System und die neuen Prozesse einzulassen. Auch die Weiterentwicklung des Systems ist dadurch stark betroffen. Die enge Zusammenarbeit zwischen Projektmitarbeitern und dem Betrieb wird einen ständigen Strom an Change-Requests erzeugen, der jeden Business Case sprengen wird. Wenn man sowas macht, muss man es also auch ganz schnell wieder sein lassen. Das kann nur für einen eng begrenzten Zeitraum ein sinnvolles Vorgehen sein.