Gerne wird von IT Managern angenommen, dass ein potentieller Dienstleister alle „lästigen“ Aufgaben in der Infrastruktur übernimmt und damit die eigene IT Organisation mit technischen Aspekten weitgehend verschont bleibt. Allerdings kann ein Dienstleister nur so gut arbeiten, wie es die Anforderungen des Kunden zulassen. Hier wird der Berater zum Mittler zwischen den beiden Welten.

Alter Wein aus neuen Schläuchen

Oftmals hört man von gestandenen IT-Managern: „Wir migrieren erst mal 1:1, und dann kümmern wir uns um die Neuerungen im Produkt“ oder „Machen Sie es in der neuen Umgebung so wie es in der Alten war.“

Diese oder ähnliche Sätze aus den Mündern gestandener IT Manager sind kontraproduktiv für ein komplexes Projekt. Denn Eines wird damit klar: Im Management des Kunden weiß man nicht, was man will und, noch schlimmer, man weiß nicht was man haben muss!

Die Aussage macht deutlich, das in der Vergangenheit weder über den punktgenauen Einsatz von Software noch über das Feedback aus den Fachbereichen besonders reflektiert wurde. Damit wurde ein reicher Schatz an Erkenntnissen aus dem Betrieb verschenkt, der so nicht mehr abschöpfbar ist. So setzt man mit dem Dienstleister eine neue Umgebung im Blindflug auf.

Folgendes möchte ich klarstellen: Natürlich gibt es Situationen, in denen genau eine 1:1 Umsetzung passt. Hier möchte ich mich zurücknehmen und den Verantwortlichen gerne assistieren, das sie wissen was sie benötigen. Und sie wissen es auch zu formulieren.

Aber in der Regel kann man Projekte, insbesondere Migrationsprojekte so nicht angehen; Sie sind zum Scheitern verurteilt.

Aus der Praxis

Ich komme gerade aus einem Projekt, indem es zwar einen Auftraggeber und einen Dienstleister gab, aber ein ausformuliertes Architektur-Konzept gänzlich fehlte. Auch eine ausführliche und vollständige Beschreibung, über das Ziel, die Funktionen und die  Wirkungsweise des am Ende stehenden Produktes suchte man vergebens. Darüber hinaus hatten Dienstleister und Kunde bislang noch nicht miteinander gearbeitet. Daraus ergab sich eine unheilige Melange aus „Try & Error“ und der Aufforderung „Mach mal was und ich sage Dir dann, ob es mir gefällt“ seitens des Kunden.

Es kam, was kommen musste: Da Anforderungen an den Dienstleister und an das Produkt nicht klar und detailliert vom Kunden formuliert wurden und die Sichtweisen auf das Produkt seines Dienstleiter und Kunde diametral waren, stritt man sich in jedem Gespräch über tatsächliche oder vermeintliche Defekte. Und davon gab es Hunderte.

Wie kam das: Anforderungen und Testverfahren waren schwammig und indifferent beschrieben; das vermeintliche Architektur Konzept hatte maximal rudimentären Charakter. Die tatsächlichen Anforderungen der Fachabteilungen wurden nicht in abgefragt und verprobt. Also war am Ende nicht klar ob die Ergebnisse der Tests zu einem Defekt geführt hatten oder nicht. Denn was für den Einen ein Fehler war, war für den Anderen ein Funktion.

Die gleiche Sprache sprechen

Darüber hinaus wurde im Projekt keine einheitliche Sprachregelung etabliert. In einer kleinen Gruppe ist das auffangbar, bei einem größeren Team (hier zwischen 35 bis 50 Personen) kommt es aber blitzartig zu den unterschiedlichsten Interpretationen von Begrifflichkeiten. Das Chaos ist unvermeidlich.

Auch hier ein Beispiel: Für eine Gruppe von Mitarbeitern sollte ein Arbeitsplatz mit einer bestimmen Produktkonstellation plattformübergreifend, unter anderem auch als VDI, bereitgestellt werden. Natürlich sollte diese Produktzusammenstellung auch auf einer anderen Plattform, beispielsweise auf einem Desktop PC arbeiten.

Nun wurde mit dem Management des Kunden wie des Dienstleisters nicht klar herausgearbeitet, dass eine VDI lediglich eine Bereitstellungsform einer Arbeitsoberfläche ist und nicht das Produkt, das für die Gruppe zur Verfügung gestellt werden soll.

Das führte in der Folge dazu, dass die Produktzusammenstellung zwar als VDI bereitgestellt wurde, es aber zum nicht mehr auf einer anderen Plattform genutzt werden konnte. Eine noch schlimmere Auswirkung hatte dieses Versäumnis: Da die Techniker des Dienstleisters davon ausgingen, das VDI nur für diese eine Gruppe eingesetzt wird, wurde die Infrastruktur auf diese Ausgangslage zugeschnitten. Die Nutzung für andere Gruppen innerhalb des Unternehmens war damit hinfällig.

So kann und darf man ein solches Projekt nicht angehen! Es wurde aus einem mittleren Projektumfang, den man sicherlich in einer optimierten Umgebung in einem Jahr bewältigen kann, ein Marathon von zweieinhalb Jahren!!

Übrigens: der Kunde hat 7.500 Mitarbeiter.

Wie funktioniert es dann?

Eine wichtige Quintessenz aus Fällen wie diesen lautet: Man wird nicht schneller im Projekt, indem man die Beschreibung der Anforderungen weglässt. Gerade in Bezug auf Dienstleister, die den Betrieb der Infrastruktur ganz oder teilweise übernehmen gelten folgende Regeln:

• Ohne klare Formulierung von Anforderungen ist der Dienstleiter nicht in der Lage Ihre Geschäftsvorfälle zu unterstützen.
• Der Dienstleister hat immer eine andere Zielsetzung als der Kunde!
• Verantwortung für IT lässt sich nicht auf den Dienstleister transferieren.
• Die IT ist der interne Dienstleister für das gesamte Unternehmen. Somit sind alle Stellen im Unternehmen Kunden der IT!

14 Handlungsempfehlungen für Sie

• Verdeutlichen Sie, wer Kunde Ihres Projektes ist.
• Beziehen Sie die Projekt- Kunden (ggf. Repräsentanten Ihrer Kunden) frühzeitig als Informations-Lieferanten in das Projekt ein.
• Achten Sie ganz besonders auf die Projektsprache.
  So hat meiner Erfahrung nach ein Softwareprodukt meist drei Verkehrsnamen, unter denen es im Unternehmen gehandelt wird: Den (ehemaligen) Projektnamen, den Produktnamen und den Namen des Herstellers (insbesondere bei spezialisierten Produkten).
• Nehmen Sie sich zu Projektbeginn Zeit! Während des Erstellens der Projektanforderungen z.B. in Form eines Lastenhefts ergeben sich mehr und komplexere Fragen, die zuvor keinem Beteiligten in den Sinn gekommen sind.
• Arbeiten Sie zur Anforderungs- Analyse mit einem kleinen Team von ein – bis zwei Architekten und zwei Technikern, Diese Werte können bei Bedarf erhöht werden; arbeiten Sie in dieser Phase jedoch nicht mit dem gesamten Projektteam. Das wird erst dann relevant, wenn die Anforderungen klar sind.
• Versuchen Sie Mitarbeiter in das Projekt zu holen, die besser sind als Sie!
• Definieren Sie die Anforderungen an Ihr Produkt auf den Punkt genau!
• Definieren Sie das Projekt – Wording auf den Punkt genau.
• Erarbeiten Sie Paradigmen des Produktes!
• Erstellen Sie einen groben Projekt-Masterplan!
• Erstellen Sie einen Architekturplan / Architekturmodell!
• Schaffen Sie Evidenzen. Alle Aussagen Ihres Konzeptes müssen zwingend bewiesen sein.
• Und glauben Sie nicht, dass Ihre Ausgangsdaten einfach so stimmen!
• Versuchen Sie in ihrer Anforderungsbetrachtung vollständig zu sein, aber bitte nicht krampfhaft (erreichen Sie 80%, die aber zu 100%)

Sind die Projektanforderungen erst einmal klar formuliert, lässt sich auch ein großes Projekt stemmen. Das Team orientiert sich dabei an Ihren Ergebnissen aus der Anforderungsanalyse und der Projektplanung.

So umschiffen Sie sauber und strukturiert potentielle Fehler und Stolperfallen. Denn das Ziel darf es nicht sein, Fehler zu beheben, sondern Fehler zu vermeiden.