Danke für den ausführlichen Kommentar! Projekte und Projektabwicklung als Standardprozess zu sehen klingt grotesk ist aber oft gelebte Praxis. Die logische Konsequenz ist es dann diesen Standardprozess oder einzelne Schritte davon gebündelt einzukaufen am besten en gros wie Schrauben. Besonders wenn die Projekte dann hohen Neuheitsgrad haben, geht das gehörig schief.

ein toller Artikel! Ich war früher IT-Services-Analyst und habe untersucht, wie große IT-Dienstleister wie IBM Services oder beispielsweise T‑Systems arbeiten, war ihre Strategien sind. Tatsächlich wird praktisch alles zum Projekt, und die Kunden wollen möglichst alles auf Ihre Branche, ihre Prozesse und natürlich ihre eigene Unternehmenskultur zugeschnitten bekommen.
Doch eines versuchen wenigstens die ganz Großen: Eine Art interne „Industrialisierung“. Man lagert als IT-Dienstleister also Teile von gleichzeitig laufenden Kundenprojekten ins (nahe) Ausland aus oder man lässt diese sogar im eigenen Hause und – jetzt kommt der Clou – bringt sie in einen „Standardprozess“, der immer gleich im Hintergrund abläuft. Daher kommt auch die Spezialisierung auf Branchen oder bestimmte Funktionen (wie z.B. App Development, Security und Testing oder Betrieb der gesamten Human Resources IT). Bei den meisten ist allerdings diese Art der Vereinheitlichung gründlich gescheitert – heute ist wieder viel Maßarbeit gefragt.

Wir haben bei uns aber noch etwas ganz anderes gelernt Für besonders kniffelige Aufgaben muss man immer mal wieder einen Experten aus dem Ausland verpflichten. Wenn ich hier einfach niemanden finde, der ein bestimmtes System auf Touren bringen kann, bleibt mir nichts anderes übrig. Wir hier haben es auf die ganz harte Tour gelernt, dass es die Aufgabe des IT-Dienstleisers als Team und Organisation ist, dem extern Eingebundenen Sicherheit zu geben, auch Teillösungen mitzuliefern und ihn mit seinem kulturellen Hintergrund zu verstehen. Uns wurde das endlich glasklar, als ein philippinischer Programmierer sein f e r t i g e s Werk von unserem Server löschte, und sein Honorar zurückzahlte. Wir hatten seine Ehre beleidigt, denn wir hatten seine Fortschritte nicht schnell genug getestet.

Vielen Dank für diesen Kommentar. Sehr schön stellen Sie nochmals den prinzipiellen Widerspruch dar, dass ein Mitarbeiter eines Dienstleisters dem Kunden gegenüber loyaler ist als dem eigenen Arbeitgeber gegenüber. Hier gilt es tatsächlich die Balance herzustellen. Die Idee der regelmäßigen Supervision, die eben nicht missbraucht werden darf um rein über Auslastung und Neuaufträge zu reden, sondern der Beziehungspflege zu dienen hat. Neben dem bewussten Herstellen eines Gravitationszentrums und gemeinsamen nutzenstiftenden Erlebnissen, wie von Franziska angeregt, halte ich die Supervision und Beziehungspflege für einen sehr wichtigen Baustein in dem Spiel. Danke!

Vielen Dank für Deinen ergänzenden Kommentar, Franziska! Natürlich habe ich das bewusst schwarz-weiß gezeichnet. Entspricht aber in großen Teilen meiner Erfahrungswelt, die einerseits aus IT-Dienstleister und andererseits aus Automobilherstellern besteht. Und da ist der beschriebene Unterschied wirklich so deutlich spürbar. Die Autobauer sind oft auch bis zur entferntesten Abteilung sehr stolz auf Ihre Produkte und identifizieren sich damit und den IT-Dienstleistern fehlt oft der Zusammenhalt. Natürlich sieht das in anderen Branchen oder in anderen produzierenden Unternehmen anders aus und ist nicht ganz so trennscharf. Dein Beispiel von den Investitionsgütern ist da ein sehr gutes. Das Produkt steht da gar nicht mehr so im Vordergrund, sondern eher die Dienstleistung dieses beim Kunden einzuführen und anzubinden. Insofern befinden sich diese Unternehmen in einem Zwischenstadium von Dienstleister und Produkthersteller und habe da sicherlich genau die gleichen Schwierigkeiten der Identifikation wie andere Dienstleister auch.

Meiner Meinung nach lassen sich diese Herausforderungen nur meistern über ein hohes Maß an Selbstorganisation in Verbindung mit kulturell intensiven, nutzenstiftenden, gemeinsamen Erlebnissen (z. B. firmeninternen BarCamps).

Dem kann ich nur voll und ganz zustimmen. Selbstorganisation hatte ich ja auch identifiziert, aber gerade die gemeinsamen Erlebnisse finde ich ebenfalls sehr wichtig. Danke!

Schaue ich mir hingegen zum Beispiel den Bereich der (erklärungsbedürftigen) Investitionsgüter an, so ist jede Markteinführung und zu einem Gutteil auch die Marktbearbeitung ein Projekt-getriebenes Geschäft. Es geht dabei stets darum, aus dem modularen Baukasten an Komponenten die Lösung (im Sinne eines Systems) in enger Abstimmung mit den Bedürfnissen des Kunden zu entwickeln und umzusetzen. Das betrifft dann alle Abteilungen quer durch das ganze Unternehmen.

Und dann stehen Industrie-Unternehmen vor denselben Herausforderungen, die Du oben beschreibst:
– zu viele Projekte gleichzeitig
– zu wenig Flexibilität, sich dynamisch an die veränderten Gegebenheiten anpassen zu können
– Projekt-Mitarbeiter, die zwischen die Interessen zweier Unternehmen geraten (das Stammhaus – der Kunde) und Gravitation von beiden Seiten empfinden oder dazwischen zerrieben werden
– Projekt-Mitarbeiter, die sich aus Abteilungsdenke lösen müssen und „Projekt-orientiert“ denken sollen, gleichzeitig in der Abteilung oder auch Matrix gebunden sind (also Diener vieler Herren sind)
– Projekt-Mitarbeiter, die sich zunehmend schwer mit ihrer Rolle, ihren Entscheidungsspielräumen und dem Sinn ihrer Aufgaben tun (oftmals noch zusätzlich verstärkt durch Konzern-Tochtergesellschafts-Strukturen auf internationalem Parkett)

Meiner Meinung nach lassen sich diese Herausforderungen nur meistern über ein hohes Maß an Selbstorganisation in Verbindung mit kulturell intensiven, nutzenstiftenden, gemeinsamen Erlebnissen (z. B. firmeninternen BarCamps).

Leider ist der Fokus aber bei vielen IT-Dienstleistern so eng und teilweise noch enger: manchen entwickeln nur, manche betreiben nur, manche machen nur die Wartung. Und diese Trennung wird ganz bewusst von manchen Kunden, gerade aus der Automobilbranche ganz bewusst gefördert um Konkurrenz bei den Lieferanten aufzubauen.