14 Gründe warum Outsourcing Projekte scheitern
Viele Outsourcing Projekte scheitern, besonders in der IT. Dabei ist es relativ egal in welches Land man outsourced. Sei es nach Deutschland, Rumänien oder Indien, werden die wichtigsten Grundlagen nicht beachtet, dann bringt die Verlagerung der Tätigkeiten wenig. In manchen Fällen kann es sogar mehr Kosten verursachen als es Nutzen bringt.
Im Folgenden sind mehrere Gründe beschrieben warum die meisten Outsourcing Projekte fehlschlagen.
1) Übergabe der Projektverantwortung
Oftmals wird die Anforderung in Form eines Anforderungsdokumentes an den Outsourcing Anbieter abgegeben. Von Zeit zu Zeit fragt der Auftraggeber nun den Anbieter wie der Status ist. Jede Woche bekommt der Auftraggeber zu hören, dass die Aufgabe gut verläuft und das alles soweit passt.
Nach mehreren Monaten freut der Auftraggeber sich auf das finale Produkt. Nur um bei der Übergabe festzustellen, dass die fertige Lösung gar nicht ist was er benötigt. Meistens stimmt die Qualität und die Performance des Produktes auch nicht.
Der Grund liegt auch darin, dass der Auftraggeber die Projektverantwortung komplett abgibt, sobald das Auftragnehmer Unternehmen mit seiner Arbeit startet. Der Auftraggeber ist meistens „erleichtert“ und denkt sich „Super, jetzt habe ich das Ganze abgegeben und brauche mich darum nicht mehr zu kümmern. Ich freue mich bereits jetzt auf die fertige Lösung“ .
Ein Outsourcing Projekt lebt jedoch vom Feedback des Kunden. Sehr schnell sollte eine erste Version vorliegen, welche der Kunde durchgängig testen kann. Sofort wird der Kunde merken ob das Projekt in die richtige Richtung geht.
Der Kunde kann mit dem Team sprechen und die unterschiedlichen Perspektiven auf die Aufgabe beleuchten. Oftmals wird es dem Kunden auch klar, dass das Team gar nicht falsch gearbeitet hat, sondern nur in die falsche Richtung.
Wichtig ist es also eng mit dem Anbieter zusammenzuarbeiten, um Fehlentwicklungen zeitnah entgegenzuwirken.
2) Fehlendes technisches Wissen
Oftmals vergibt der Auftraggeber Projekte, über deren technischen Hintergründe er/ sie wenig Ahnung hat. Dadurch ist es dem Kunden fast unmöglich, Zwischenstände auf deren technische Qualität zu prüfen.
Erst spät im Projekt werden dann Performance Probleme sichtbar. Dann ist es meistens zu spät und man kann die Software, oder was auch immer, von Grund auf neu erstellen.
Auf Kundenseite sollte es also einen Projektleiter oder technischen Leiter geben, welcher die Aufgaben des Outsourcing Teams bewerten kann.
3) Fehlende Nähe zum Team
Wie im Punkt 1 bereits beschrieben, werden Aufgaben abgegeben und man erwartet nach dem Fertigstellungsdatum das fertige Produkt.
Hierbei ergibt sich eine weitere Herausforderung. Wenn das Team keine Nähe, dass heisst, keine öfter stattfindenden Meetings, Konferenzen, Kennenlern-Aktionen, Skype Calls mit dem Kunden hat, dann entsteht mit der Zeit eine sehr grosse Distanz zum Auftraggeber.
Die Entwickler/ Mitarbeiter im Outsourcing-Team werden sich mit der Zeit wundern:
- Wer ist das Auftraggeber-Unternehmen überhaupt?
- Welche Produkte und Dienstleistungen bietet das Unternehmen an?
- Was ist die Unternehmenskultur?
- Wer sind die Leute hinter der Firma?
- Sind das sympathische Leute?
- Wie helfen deren Lösungen wiederum den Kunden des Kunden?
- Warum haben die uns beauftragt?
- Wie können wir helfen?
- Was wird von uns erwartet?
Fragen über Fragen werden sich mit der Zeit auftun.
Auch aus einer kulturellen Sichtweise ist diese „Nähe“ wichtig. In Ländern wie Indien, werden Menschen mit denen man wenig zu tun hat, als „Fremde“ betrachtet, für die es meistens nicht Wert ist, grossartige Leistungen zu erbringen.
Auch in Deutschland macht es Sinn, mit Teams vor Ort, so eine Nähe aufzubauen. Auch diese freuen sich wenn diese Wissen, für wen sie eigentlich den ganzen Tag arbeiten.
4) Fehlende langfristige Denkweise
Wenn Aufgaben verlagert werden, wird oftmals sehr kurzfristig gedacht. Ein Online Portal oder ein anderes Projekt wird als Auftrag vergeben und wenn die Programmierung fertig ist, gilt die Aufgabe als abgeschlossen.
Was ist jedoch wenn neue Features entwickelt werden sollen? Wenn nach einigen Monaten Bugs/ Fehler auftreten? Wenn das System upgedated werden muss? Wenn die Lösung in anderen geographischen Regionen angeboten werden soll? Wenn die Lösung auf andere Industrien und Kunden angepasst werden muss?
Oftmals ist es nicht einfach möglich, dass Outsourcing Team zeitnah mit der Aufgabe zu beauftragen. Das Team wird höchstwahrscheinlich bereits an anderen Aufgaben arbeiten.
Daher ist es wichtig langfristig zu denken und diese langfristige Planung auch mit dem Auftraggeber zu besprechen. Der Auftragnehmer weiss dann, das es weitere Aufgaben gibt, und das er dafür Mitarbeiter einplanen sollte.
Besonders in IT Aufgaben ist eine langfristige Denkweise empfehlenswert. Denn der Projekterfolg stellt sich meistens mit der Weiterentwicklung der jeweiligen Software ein und meistens nicht mit der Fertigstellung der ersten Version.
5) Sprachkenntnisse und kulturelle Unterschiede
Lagern Sie ins Ausland aus? Dann wird meistens auf Englisch kommuniziert. Viele vergeben Aufgaben ins Ausland, ohne die notwendigen Fähigkeiten in dieser Sprache im Unternehmen zu besitzen.
Jetzt muss man nur noch ein Unternehmen im Ausland wählen, das selbst auch keine guten Sprachkenntnisse im Englischen besitzt. Dann ist das Desaster meistens vorprogrammiert 🙂
Auch werden meistens die „Basics“ im Bereich kulturelle Unterschiede nicht beachtet, auch wenn diese Unterschiede oftmals nur gering sind. Weiter unten im Artikel mehr dazu.
6) Technische Umsetzbarkeit
Planen Sie sehr stark innovative Lösungen? Dann ist es eventuell besser In-House zu entwickeln. Für ein Outsourcing Unternehmen ist es meistens schwer solche Lösungen umzusetzen. Auch weil es bei solchen Projekten sehr viele Unsicherheiten gibt.
Das Auftragnehmer-Unternehmen wird sich fragen:
- Werden wir in der Lage sein, diese Innovation umzusetzen?
- Wie wird der Aufwand für diese Tätigkeiten bestimmt? Wird der Kunde die langen Planungs und Programmierphasen genehmigen?
- Was passiert wenn wir scheitern?
Es ist also besser, auf Aufgaben zu setzen, bei denen die technische Umsetzbarkeit bereits bekannt ist. Zum Beispiel braucht man eine Print-Lösung, welche Unternehmensweit eingesetzt werden soll. Solche Lösungen gibt es bereits und man weiss bereits, in welche Richtung die technische Umsetzung geht.
Anders wäre es, wenn man zum Beispiel eine neue Art von Suchmaschine programmiert, welche zum Beispiel anhand von Gesichtserkennung funktioniert. Solche Lösungen gibt es noch nicht und dann wird es auch schwer einzuschätzen wie der Erfolg dieser Aufgabe aussehen wird.
7) Planung der Weiterentwicklung
Wenn Aufgaben verlagert werden, sollte man bereits früh mit einer guten Planung beginnen. Dinge wie die spätere Weiterentwicklung, die Erfolgsfaktoren, die nächsten Versionen, die späteren Nutzergruppen, etc. sollten bereits vor dem Start feststehen.
Klar, eine genaue Beschreibung ist fast nie möglich, besonders in IT Projekten, aber man kann zumindest eine grobe Planung vor dem Beginn der Arbeit des Auftragnehmers beginnen.
8) Kundenseitiges Testing der Lösung
Viele Kunden testen die Versionen und Lösungen nicht, welche sie vom Outsourcing Unternehmen bekommen.
Meistens wird davon ausgegangen, dass der Auftragnehmer die Lösung bereits getestet hat. Dies ist natürlich fast immer der Fall. Nur ist es erheblich schwerer für das Entwicklungsunternehmen selbst Fehler festzustellen. Oftmals laufen auf den Systemen die gleichen Konfigurationen.
Der Kunde dagegen kann die Lösung in seiner eigenen Umgebung nutzen. Schnell wird klar, ob die Bedienung einfach verständlich ist und ob die Lösung auch auf anderen Systemen, als auf dem des Auftragnehmers funktioniert.
Zusätzlich macht es auch Sinn, das System zum Testen an Drittunternehmen abzugeben. Es gibt hierfür spezialisierte Firmen, welche das übernehmen können.
9) Keine Prozesse vorhanden
Ein weiterer Grund warum solche Verlagerungen scheitern ist, weil Auftraggeber keine Prozesse definiert haben.
Die folgenden Dinge sind dadurch meistens nicht klar:
- Wie ist Erfolg definiert?
- Wer im Kundenunternehmen testet die Lösung?
- Wie werden Zwischenschritte geprüft?
- In welchen Zeiträumen gibt es Meetings, um den Status zu besprechen?
- Wie sieht der Prozess aus, so dass sich das Kundenunternehmen und der Auftraggeber besser kennenlernen?
Dies sind nur einige Fragen, welche im Zusammenhang mit den Prozessen beantwortet sein sollten, bevor das Projekt startet.
Ohne passende Prozesse funktioniert eine gute Zusammenarbeit kaum.
10) Die Teammitglieder sind unbekannt
Der Auftraggeber hat bei Verlagerungen meistens nur Kontakt mit dem Projektleiter und dem Vertriebsmann beim Auftragnehmer.
Er weiss meistens nicht, wer genau an dem Auftrag arbeitet. Sind das nun Senior Entwickler? Oder sind das alles Junior Entwickler, welche keine wirkliche Erfahrung haben?
Alleine das kann einen erheblichen Unterschied machen.
Aber nicht nur aus diesem Grund macht es Sinn, sich mit den einzelnen Teammitgliedern zu beschäftigen. Auch kann man mit der Zeit den Kommunkationsstiel eruieren und weitere Dinge erkennen.
11) Das falsche Outsourcing Modell
Das Modell der Zusammenarbeit ist entscheidend für den Erfolg der Verlagerung der Arbeiten.
Zum Beispiel gibt es die Wasserfall-Methode. Alle Anforderungen werden zum Anfang definiert und zum Ende des Projektes bekommt der Kunde die fertige Lösung. Das hört sich gut an, in diesem Beitrag wurde bereits erwähnt, warum dies eine mehr als nicht ideale Möglichkeit der Zusammenarbeit ist.
Auch sind sogenannte Fix-Preis-Modelle nicht ratsam. In fast allen Projekten wird mit der Zeit klar, dass die Anforderungen umformuliert werden müssen. Am Ende hat man eine ganz andere Liste an Teilbereichen die umgesetzt werden sollen. Das Auftraggeber Unternehmen wird jedoch meistens trotz der Änderungen nicht bereit sein, Änderungen im Budget vorzunehmen „Es handelt sich ja um ein Fix-Preis-Projekt“. Auch das Auftragnehmer Unternehmen weiss das. Und so bestehen viele Auftragunternehmer, man könnte sagen „Stur“, auf den initialen Anforderungen, so dass sich der Aufwand nicht ändert.
Besser sind Zusammenarbeitsmodelle in welchen die Entwickler dediziert nur für einen Kunden arbeiten. Hierbei lernen die Entwickler das Kundenunternehmen und das dazugehörige Team immer besser kennen. Diese verstehen mit der Zeit auch, warum bestimmte Features gebaut werden und welche Qualtätsstandards das Kundenunternehmen erwartet.
12) Ein freundlicher Umgang
Durch die Unsicherheit darüber, wer den eigentlich an dem Projekt arbeitet und durch die sonstige Unsicherheit, bei der Wahl des falschen Zusammenarbeitsmodells, wird der Auftraggeber meistens sehr unfreundlich im Umgang mit dem Auftragnehmerunternehmen sein.
Oftmals wird das Outsourcing Unternehmen, ähnlich zu einem Fussball angesehen, den man ab und zu treten muss, so das er ins Ziel gelangt (in diesem Fall ins Tor).
Da es sich jedoch um Individuen handelt, die diese Tritte zu spüren bekommen, wird die Motivation relativ schnell sinken und diese werden dann bei diesem „Spiel“ nicht mehr mitmachen.
Daher sollten Sie das ausgelagerte Team genau so freundlich und zuvorkommend behandeln, wie Sie es mit eigenen Mitarbeitern, Kollegen und Kunden machen würden. Die Motivation wird dadurch auf allen Seiten mit der Zeit erheblich steigen.
13) Power Distance Index
Nicht verzagen, die Überschrift sieht komplizierter aus, als sie ist 🙂
Der Power Distance Index (PDI) ist einer der wichtigsten Punkte in diesem Beitrag. Diese Kennzahl wurde von Geert Hofstede, einem niederländischen Kulturwissenschaftler, entwickelt.
Nach dieser Kennzahl gibt es unterschiedliche „Distanzen“ zwischen Vorgesetzten und deren untergeordneten Mitarbeitern, in verschiedenen Ländern.
In Deutschland ist dieser Index zum Beispiel sehr gering.
Ein Beispiel: In Deutschland frägt ein Teamleiter den Mitarbeiter „Bekommen wir die fertige Lösung am Freitag?“
Der Mitarbeiter wird daraufhin offen sagen „Nein, Freitag ist leider nicht realistisch. Es gibt da noch Punkt X und Punkt Y welche ausgeführt werden müssen“.
Dem Teamleiter ist sofort klar, dass er den Termin von Freitag auf einen anderen Zeitpunkt verschieben muss.
In Indien ist dieser Index (also die Distanz zwischen Vorgesetzten und untergordneten Mitarbeiter) sehr hoch.
Ein Beispiel: Ein deutscher Teamleiter frägt den Entwickler in Indien „Bekommen wir die fertige Lösung am Freitag?“
Der Mitarbeiter sagt daraufhin: „Ja, ich denke es sollte möglich sein, die Lösung bis Freitag fertigzustellen“.
Jetzt notiert sich der Teamleiter aus Deutschland, den Freitag als Fertigstellungstermin und kommuniziert das intern, als auch eventuell zum Kunden hin.
Der Grund warum der Entwickler nicht offen sagt, dass es nicht bis Freitag fertig werden kann ist, weil er sein „Gesicht wahren“ möchte. Das ist in vielen Kulturen, nicht nur in der indischen, der Fall. Auch in Deutschland passiert das in einigen Situationen.
Daher sollte das Auftragnehmerunternehmen wissen, welcher ungefähre Power Distance Index im jeweiligen Land besteht, um so zu wissen, dass in manchen Ländern, zum Beispiel, Fragen anders gestellt werden müssen.
Im obigen Beispiel, mit dem deutschen Teamleiter und dem indischen Entwickler, hätte man zum Beispiel unterschiedliche Fragen stellen müssen, um auf die gleiche Antwort zu kommen, wie beim deutschen Entwickler auch. Oder man hätte die Frage so stellen müssen, so dass der indische Entwickler „sein Gesicht“ wahren kann.
14) Mehrere Projekte gleichzeitig
Um „schneller“ voranzukommen, werden oftmals gleichzeitig mehrere Aufgaben an das Outsourcing Unternehmen vergeben.
Dies kann jedoch im Verlauf zu Verwirrungen führen. „Ging es bei der Email nun um Projekt A, um Projekt B oder um Projekt C?“
Gibt es ein hohes PDI, dann wird der indische Projektleiter diese Frage eventuell nicht nach Deutschland weitergeben und geht einfach davon aus, was er denkt, um welches Projekt es sich handelt. Dies ist jedoch meistens nicht zu hundert Prozent akurat.
Daher sollte man sich auf eine Aufgabe beschränken, um so den passenden Kommunkationsfluss sicherzustellen.
Fazit
Auslagerungen an Drittunternehmen können zum Erfolg führen. Dafür muss jedoch das Drittunternehmen nicht als solches wahrgenommen und behandelt werden. Besser ist es, dieses Unternehmen als Partnerunternehmen oder noch besser, als Teil des eigenen Unternehmens zu sehen.
Zudem sollte eine langfristige Denkweise verankert werden, welches die Planung und Implementierung von passenden Prozessen beinhaltet. Es müssen keine detailierten Pläne oder elaboraten Prozesse sein. Jedoch sollten die Eckpunkte, Richtlinien, Ansprechpartner und andere wichtige Dinge im vornherein klar sein, oder mit dem Auftragnehmer Unternehmen während des Projektstarts eruiert werden.
Welche Erfahrungen haben Sie gemacht?
Bilder: Flickr.com/ whatleydude/ abductit/ ter Burg/ Chan
Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt und Softwareprojekte abwickelt.
Guter Beitrag.