Wie wo was Nearshore? - Teil 2
Heute möchte ich ein wenig zu den verschiedenen Gestaltungsmöglichkeiten für Nearshore-Projekte schreiben. Zunächst hängen diese natürlich von der Natur des Projektes ab, ein klassisches Entwicklungsprojekt bietet andere Optionen als z.B. ein Wartungs- oder ein Testprojekt. Nehmen wir also der Einfachheit halber einen Kunden an, der eine Neuentwicklung im Bereich Business Anwendung umsetzen will, mittlere Größenordnung (200 bis 300 PT).
Szenario 1: Die Anforderungen für das Projekt sind schwer zu erfassen und erfordern viel fachliches Knowhow. Die Spezifikation dieser Anforderungen muß daher vor Ort erfolgen und geschieht in mehreren Iterationsschritten mit zahlreichen Workshops, in denen unterschiedliche Anwendergruppen heterogene Anforderungen äußern.
Projektorganisation: Ein “Brückenkopf” wird beim Kunden vor Ort zu Projektbeginn durchgehend eingesetzt, der mit dem Kunden zusammen die Anforderungen sammelt, auswertet und in eine Spezifikation gießt. Dieser Brückenkopf kann entweder ein deutscher Projektleiter / Analyst sein (der natürlich die Nearshore-Kollegen kennt) oder ein Nearshore-Projektleiter /-Analyst, der diese Aufgabe ausfüllen kann. Die Kommunikation findet zwischen Kunde und Brückenkopf sowie zwischen Brückenkopf und Nearshore-Team statt. Diese Gestaltung kann nach Abnahme der Spezifikation auch derart aufgelöst werden, daß der Kunde dann direkt mit dem Nearshore-Team kommuniziert. Das Projekt wird dann entweder als Festpreis umgesetzt oder nach Aufwand, abhängig von Detaillierung und Qualität der Spezifikation und von der zu erwartenden Volatilität im Projekt. Letzteres heißt konkret: Wenn zu erwarten steht, daß der Kunde die Anforderungen nach Abschluß der Spezifikation häufig ändert oder erweitert bzw. viele kleinere Phasen mit neuen Anforderungen unmittelbar anschließend zu erwarten sind, dann würde ein Festpreis einen immensen Overhead produzieren, alleine um die Change Requests zu verwalten. “Time and Material” ist hier erfahrungsgemäß die einfachere und kostengünstigere Variante.
Szenario 2: Der Kunde hat ein hervorragend spezifiziertes Projekt zu vergeben. Funktionale und nicht-funktionale Anforderungen sind sauber definiert, die UI ist entsprechend Standard-Layouts vorgegeben, sämtliche Schnittstellen und andere relevanten technischen Formate liegen auf dem Tisch.
Projektorganisation: Dieses Paket kann z.B. im Rahmen eines Workshops beim Kunden vor Ort an einen Nearshore-Projektleiter übergeben werden, der als zentraler Ansprechpartner für dieses Projekt dient. Er ist dafür verantwortlich, das Projekt mit seinem Nearshore-Team aufzusetzen und durchzuführen. Ein Festpreis bietet sich an, die gesamte weitere Organsiation des Projektes bis hin zur Lieferung und Abnahme kann beim Nearshore-Partner liegen und von diesem verantwortet werden.
Szenario 3: Der Kunde hat eine Vielzahl von kleineren bis mittleren Projekten oder Versionen innerhalb eines Projektes (z.B. typisch bei Produktentwicklungen). Der Aufwand, um für jedes einzelne kleine Projekt oder jede Version eine abnahmefähige Spezifikation zu erstellen, wäre recht hoch und ist aus organisatorischen Gründen nicht zwingend erforderlich.
Projektorganisation: Hier macht es wenig Sinn, mit Pflichtenheften und Festpreisen zu hantieren, das Change Management würde vermutlich mehr Overhead produzieren als das gesamte Projektvolumen nach Aufwand beträgt. Daher ist der Kunde am besten beraten, für den Zeitraum, den er selbst projektseitig überschauen bzw. prognostizieren kann, ein festes Kontingent von Nearshore-Mitarbeitern als “sein” Team einzukaufen. Damit kann er sicherstellen, daß für alle Projekte bzw. Produktversionen immer die gleichen Nearshore-Kollegen zuständig sind, keine permanenten Einarbeitungen nötig sind, zeitraubende Festpreis-Verhandlungen entfallen und der Aufwand, der sonst in die X-te Review einer Spezifikation investiert würde, lieber für die Entwicklung oder Qualitätssicherung zur Verfügung steht. Natürlich liegt das Risiko für die Qualität des Anforderungs- und Projektmanagements annähernd komplett beim Kunden, ebenso trägt er die Verantwortung für eine gleichmäßige Auslastung des Teams. Unter den entsprechenden Voraussetzungen ist das aber tatsächlich eine sehr effiziente Organisationsform, soz. als eine verlängerte Werkbank. Hier muß natürlich vom Nearshore-Partner sichergestellt werden, daß seine Aufwände transparent sind und möglichst im groben Rahmen vorab mit dem Kunden besprochen werden. Ebenso ist eine sehr gute und schnelle Kommunikation der Beteiligten zwingend erforderlich. Unter dem Strich aber bleibt es eine Projektform, die starkes gegenseitiges Vertrauen voraussetzt.
Wir haben in den vergangenen Jahren alle diese Szenarien erlebt und durchgespielt. Und mit allen Szenarien erfolgreich Nearshore-Projekte umgesetzt. Natürlich gibt es noch zahlreiche Nuancen und Facetten, aber im Großen und Ganzen lassen sich mit diesen Spielarten die meisten Fälle abdecken.