Projekt-Management

Wie man 1.700 Clients erneuert

05.09.2012
Von 
Karin Quack arbeitet als freie Autorin und Editorial Consultant vor allem zu IT-strategischen und Innovations-Themen. Zuvor war sie viele Jahre lang in leitender redaktioneller Position bei der COMPUTERWOCHE tätig.

Die Lehren aus dem Projekt

1. Was viel Zeit kostet:

Für Projektplanung, Softwarepaketierung, Feintuning der Clients, eine intensive Testphase und sorgfältige Qualitätskontrolle wurde ein knappes Jahr veranschlagt. Das erwies sich im Nachhinein immer noch als zu wenig. Auch auf das Testing wurde viel Zeit verwandt, obwohl das den Zeitplan durcheinander brachte.

2. Die Anwender ins Boot holen:

Auf Workshops in den einzelnen Instituten durften die User ihre Wünsche und Anregungen geben. Das sei in den Fachbereichen sehr gut angekommen, so Köllhofer. Einige der Ergebnisse: Die User wollten auch offline arbeiten können, sie fühlten sich von der Konfiguration eingeschränkt, und sie bemängelten das lahme Tempo von Office.

3. Pilotphase ernst nehmen:

Ab Mai 2011 bildeten fünf Institute und zwei Abteilungen der Generalverwaltung die Vorhut für den flächendendeckenden Rollout des neuen Client. Unterstützt wurde die MPG dabei von den externen Dienstleistern Datagroup und Hewlett-Packard Education Services. Die Installation übernahm die Datagroup, die vorher schon für den Helpdesk verantwortlich gezeichnet hatte, und das laut Rahmenvertrag auch in den kommenden zwei Jahren tun dürfte.

Ein Pilot ist wie eine Generalprobe: Wenn alles läuft, wie geschmiert, hakt es oft bei der Aufführung vor dem ganz großen Publikum. In diesem Fall traten jedoch schon beim Praxistest einige Fehler auf, die vor dem Rollout in der Breite tatsächlich beseitigt wurden. Da bereits der Pilot verspätet gestartet war (im Mai statt im Januar), schob sich das Projekt dadurch noch mehr in Richtung Jahresende.

4. Allzu straffe Zeitplanung:

Dass sich Teams erst mühsam aufeinander einspielen müssen, wird bei den meisten Projekten übersehen. Auch in diesem Fall musste die zeitliche Planung im Projektverlauf angepasst werden. Eigentlich hatte der Rollout schon im September 2011 abgeschlossen sein sollen. De facto dauerte es zwei Monate änger. Pro Woche wurden zwei bis drei Institute umgestellt. Demnächst wollen die Verantwortlichen mehr Reserven in den Zeitplan einbauen.

5. Technische Evaluierung schwierig:

Leider sind Softwareprogramme nicht immer so kompatibel miteinander und mit dem Betriebssystem, wie die Anbieter es versprechen. Das fiel vor allem bei der Verschlüsselungssoftware von Sophos (vormals Utimaco) ins Gewicht, die laut Köllhofer zunächst "etwas hakelig" daherkam. Auch die Anwendungssoftware sei teilweise noch nicht auf Windows 7 vorbereitet gewesen. Einige technische Probleme machten sich erst beim Rollout bemerkbar.

6. Begleitende Schulung hilfreich:

Projektleiter Otfried Köllhofer: "Manche Anwender tun sich etwas schwer mit dem Umstieg."
Projektleiter Otfried Köllhofer: "Manche Anwender tun sich etwas schwer mit dem Umstieg."
Foto: MPG/Axel Griesch

Zum ersten Mal unterstützte die MPG den Rollout durch eine umfangreiche Schulung der Anwender. "Manche Anwender tun sich ja schwer mit so einem Umstieg", weiß Köllhofer. Für die Einweisung übernahm HP die Verantwortung. Der Dienstleiter rückte mit mobilen Schulungsräumen an, wo die Mitarbeiter in das System eingewiesen wurden, während gleichzeitig ihre Arbeitsplätze neu installiert wurden.Die Schulungen dauerten etwa sechs Stunden. Sobald die User an ihren Arbeitsplatz zurückkehrten, konnten sie das Gelernte anwenden, denn in der Zwischenzeit war ihr Rechner eingerichtet. Beim nächsten Mal, so Köllhofer würde er die Schulung zeitlich etwas straffen, damit danach bis zum Ende des Arbeitstags noch genug Zeit für erste Erfahrungen und gegebenenfalls Rückfragen an die Schulungsleiter bliebe.

7. Zuviel Mitspracherecht und Flexibilität:

Die Planung der Rollout- und Schulungstermine lief nicht optimal, weil die Anwender ihre Terminbuchungen nicht immer einhielten. So wurde die beabsichtigte Parallelität von Installation und Schulung teilweise ausgehebelt. Darüber hinaus versäumten es einige User mit Sonderkonfigurationen oder speziellen Softwareanwendungen, ihre Anforderungen vorab zu melden, was zu Mehraufwand beim Rollout führte.

8. Jede Installation begleiten:

Die MPG schickte den Dienstleister nicht allein zu den Anwendern. Vielmehr gehörte zu jedem Team auch ein eigener IT-Mitarbeiter, der nicht direkt mit dem Rollout beschäftigt war, sondern für erste Fragen zur Verfügung stand und so dafür sorgte, dass die Tekkies "in Ruhe installieren konnten", wie Köllhofer augenzwinkernd sagt. Willkommener Nebeneffekt: Der MPG-Mitarbeiter konnte etwaige Problem direkt aufnehmen und rückmelden: "Die Beschwerden werden ja sonst beim Dienstleister abgeladen und kommen hier unter Umständen gar nicht oder schon verfälscht an", erläutert Suckfüll.

9. Feedback hochwillkommen:

Für Verbesserungsvorschläge und Anregungen hatte das AP2010-Team eine eigene E-Mail-Adresse eingerichtet, die nach Projektschluss noch fünf Monate verfügbar blieb.

10. Beim nächsten Mal wird Vieles besser:

Das Team würde beim nächsten Mal früher eine Configuration Management Database (CMDB) nutzen. Insgesamt müsse noch mehr Zeit für Paketierung, Vorplanung und Pilot eingerechnet werden, damit auch wirklich alle Pakete und die notwendigen Mitarbeiter zum Zeitpunkt X bereitstehen, so die Selbstkritik. Diesmal konnten nicht alle Anforderung vor dem Rollout umgesetzt werden, so beispielsweise die Plattenverschlüsselung, die aus dem Projekt rausgelöst wurde und separat umgesetzt wird. Wie Köllhofer und Suckfüll einräumen, gab es dieses Mal noch einige Reibungsverluste. Die sollen beim Projekt "AP 2014" vermieden werden, das im kommenden Jahr an den Start geht.