Umfrage
Woran Software-Entwicklung im Nearshoring scheitert
Wichtig: Projekte einschließlich Benutzersicht verstehen
Wenn Auftraggeber Schwierigkeiten allein auf die mangelnde Kompetenz der Auftragnehmer schieben und mit rein technischen Schulungen zu beheben versuchen, ignorieren sie das vorhandene Bedürfnis, das Projekt bis hin zur Benutzersicht zu verstehen. Hier wird vergessen, den Auftraggeber als gleichwertigen Partner zu sehen, dessen Vorbildung nicht unbedingt eine geringere sein muss.
Im Vergleich mit einer anderen Studie, die wir in Deutschland, den Niederlanden, Finnland und Belgien in ähnlich umfangreichen Projekten ohne Nearshoring oder Offshoring, aber mit Unterbeauftragung vorgenommen haben, wurden insbesondere folgende Unterschiede beobachtet:
Die Software-Architekten kommunizieren viel intensiver mit den Requirements Engineers, jedoch ebenfalls nicht mit den Endanwendern.
Trotzdem hatten sich die Architekten durch jahrelange Tätigkeit umfangreiches Domänenwissen angeeignet. Sie bezeichneten dies als unabdingbar, um fehlende oder unvollständige Anforderungen zu identifizieren.
ISO-Standards wurden hier gemeinsam bei Auftraggeber und Auftragnehmer verwendet und führten nicht nur zu einer Harmonisierung der Arbeitsprozesse, sondern auch der Spezifikationsvorlagen und verwendeten Terminologien.
In diesen Projekten waren die Architekten an der Entscheidung über Qualitätsanforderungen aktiv beteiligt, basierend auf ihrem technischen und ihrem Domänenwissen. Der Maßstab ihrer Entscheidungen war der Business Case des Projekts. Beim Aushandeln von Qualitätsniveaus verwendete daher der Architekt den Business Case, um die Auftraggeber zu überzeugen und ihre "Sprache zu sprechen".
Es scheint, dass in diesen Projekten innerhalb desselben mitteuropäischen Kulturkreises anders zusammengearbeitet wird als im Nearshoring (und vermutlich auch Offshoring): mehr auf Augenhöhe und infolgedessen mit besserer inhaltlicher Abstimmung.
Dagegen scheinen die unterschiedlichen Kulturkreise, die im Offshoring und Nearshoring oft als Hauptproblem angesehen werden, weniger Gewicht zu haben als bisher angenommen. Frühere Studien haben schon gezeigt, dass verschiedene Firmenkulturen viel relevanter sind. In einer Studie zeigten sich Differenzen umso eher, je mehr Firmen am Projekt beteiligt waren. Dagegen hatten die Teamgröße und die geographische Verteilung der Mitarbeiter einen nur geringen, statistisch nicht signifikanten Einfluss.
Passend dazu zeigte eine Fallstudie bei Microsoft, dass bei der Softwareentwicklung innerhalb einer Firma der Qualitätsunterschied des Codes bei der international verteilten Entwicklung kaum schlechter ist als bei der Entwicklung innerhalb derselben Niederlassung. Das lässt sich durch firmenweite Standards und gemeinsames Wissen erklären. In einer anderen Microsoft-Studie wurde ein negativer Effekt von organisationalen Unterschieden auf die Codequalität festgestellt. Dieser wiederum kann durch einen guten Software-Engineering-Prozess deutlich reduziert werden.
- Die zehn teuersten Outsourcing-Fehler
Eine interne Studie von ISG (Information Service Group) hat die 10 „teuersten“ Fehler im Rahmen globaler Transformationen zusammengestellt und mögliche „Lessons Learned“ für andere Projekte in dem „ISG IT-Infrastructure Transformation Fahrplan“ zusammengefasst. Dies beinhaltet den gesamten Verlauf einer Transformation, inklusive möglicher Sourcing-Transaktionen. - Der Vertrag
Beistell-Leistungen aller Parteien müssen im Vertrag im Detail dokumentiert sein und über die gesamte Transformation laufend gemessen werden – auch ein fertiger Outsourcing-Vertrag wird weiter verhandelt! - Change-Management
Das zukünftige Betriebsmodell und die Vision der Transformation (Future Mode of Operation – FMO) wird in der Organisation nicht ausreichend durch Change Management verankert und bringt Widerstand auf allen Mitarbeiterebenen. - Vorteile darstellen
Benefits der Transformation verschwinden schnell aus dem Bewusstsein der Stakeholder und werden am Ende nicht mehr der Transformation zugeordnet – sehr wohl aber die Fehler in der Service Delivery. - Schlechte Verzahnung
Parallele Projekte und Linienarbeit sind nur unzureichend mit der Transformation verzahnt und verschwenden damit unnötig Ressourcen, Budget und Zeitpläne. Risiken werden nur selten ganzheitlich und eher pro Initiative gemessen, während das Business zeitgleich alle Transformations- und Linien-Initiativen mit den gleichen Mitarbeitern bearbeitet. - Die Übergabe der Transformation in den Betrieb
Oftmals fehlt der Betriebsorganisation die Nähe zum Projekt und die Übergabe erfolgt zu schnell. Viele offene Punkte bleiben für die Mitarbeiter im Betrieb ungeklärt, was zu Konflikten führen kann. - Partnerschaften
Jegliche kommerziellen Verhandlungen gilt es durch das Vertrags-Management vom operativen Projektgeschäft zu trennen. Projektteams sollten sich auf die Erfüllung der Projektziele konzentrieren und Empfehlungen abgeben. Das Vertrags-Management kümmert sich hingegen um die kommerziellen Aspekte, bei denen auch einmal mit härteren Bandagen gekämpft werden darf. - Alte Verträge und Services (Ramp Down)
Oft gerät in der Transformations-Aktivität die fristgerechte Kündigung bestehender Verträge in Vergessenheit und Services werden nicht entsprechend heruntergefahren. Wird dieses Thema vernachlässigt, rechnet sich möglicherweise das Projekt nicht mehr. - Unklare Governance und Entscheidungswege
Nur wenn das Thema klar beschrieben und entsprechend in der Kunden- und Providerorganisation gelebt wird, kann die Transformation mit realistischen Zeitplänen durchgeführt werden, sonst entstehen, neben einer Verzögerung, zusätzliche nicht steuerbare Abhängigkeiten. - Andere Länder, andere Sitten
Was in Deutschland gut ist, muss in den USA oder Spanien noch lange nicht funktionieren. Viele Unternehmen vernachlässigen bei der Einführung globaler Services immer noch die Gegebenheiten lokaler Märkte. So zum Beispiel regulatorische Anforderungen, unterschiedliche Kulturen oder auch spezielle rechtliche Herausforderungen. - Standardisierung
Am Anfang steht ein Standard. Wieviel wird davon aber am Ende eingehalten oder doch den Anforderungen des lokalen Business zu Gunsten verworfen? Globale Business Case bauen in der Regel auf Standards – fehlende Governance verhindert an vielen Stellen noch heute bis zu 20 Prozent höhere Standardisierung durch globale Transformationen.
Bitte nicht "von oben herab"
Daraus folgt, dass man kulturelle Unterschiede bei der internationalen Softwareentwicklung nicht als unüberwindliche Barriere ansehen sollte und vor allem nicht als Begründung dafür, einem Offshoring-Partner von oben herab Bedingungen zu diktieren. Eine partnerschaftliche Zusammenarbeit auf Augenhöhe mit gemeinsam verwendeten Standards, dem Austausch von Wissen und gemeinsamen Entscheidungen ist möglich und führt zu besseren Projektergebnissen.
Das passt auch zu den Ergebnissen einer anderen Studie, die zeigte, dass Kommunikation in der verteilten Entwicklung viele auftretende Probleme zu lösen im Stande war. Das Fazit dieser Studie lautete: Kommunizieren Sie mit Ihrem Partner möglichst oft und direkt (Face-to-Face), in jedem Fall sofort, wenn eine Frage auftritt, und unterstützt durch formale Regeln, Werkzeuge und eine gemeinsame Terminologie. (hv)