Projekt-Neustart nach dem Scheitern

	Ganz einfach: Damit IT-Projekte nicht scheitern, sollten die Anforderungen der Anwender richtig eingeschätzt werden. Foto: MEV Verlag

Es hätte so schön sein können: Der COO (Chief Operating Officer) eines großen US-Unternehmens wollte den technischen Außendienst durch Automation unterstützen und setze sich dafür mit der IT zusammen. Gemeinsam suchte man ein Terminplanungs- und Dispatching-System aus, verteilte GPS-fähige Handhelds unter den Service-Technikern und schulte Techniker wie Dispatcher monatelang im Umgang mit dem neuen System. Doch das Projekt scheiterte, wie ein Report von McKinsey beschreibt.

Scheitern heißt: Die Außendienst-Mitarbeiter steigerten ihre Produktivität entgegen aller Erwartungen nicht. Die Kunden erhielten auf ihre Anfragen auch nicht schneller Antwort als zuvor. Was die Erfahrungen der Endnutzer mit der neuen Anwendung betrifft, waren die Meinungen gespalten: Die einen freuten sich über weniger Administrations-Aufwand, die anderen klagten, das System habe mit ihrem Arbeitsalltag nichts zu tun. Obendrein sei es aufwändig.

COO und CIO mussten also von vorn anfangen. Beim Neustart machten sie es schlauer: Sie suchten sich einen einzelnen Bereich heraus und beschlossen, die Software vor einem großen Roll-Out zu testen. Am Rechner simulierten sie Abläufe und mögliche Veränderungen durch Automation.

Dabei zeigte sich, dass die 20 beobachteten Außendienstmitarbeiter zum Beispiel kein GPS brauchen. Selbst dann, wenn sie in den Stammgebieten von Kollegen aushelfen, weil dort Not am Mann ist, kennen sie die Gegend gut genug. Das war denn auch einer der Punkte gewesen, der die Anwender genervt hatte.