Warum scheitern größere IT-Projekte so oft?

Eine Hinführung zu gewollt kontroversen Diskussionen oder warum braucht man Change-Management?

IT-Projekte im Allgemeinen und Software-Entwicklung im Besonderen sind komplex, und abhängig von vielen Rahmenbedingungen. Dabei wird die IT-Welt weiterhin immer komplexer, die technischen Möglichkeiten und Ansätze werden jeden Tag mehr und damit wachsen auch die Kombinationsmöglichkeiten wie Technik im Projekt-Alltag angewandt werden und als Lösung für die Anforderungen unserer Kunden dienen kann. Wir haben gelernt mit dieser Komplexität umzugehen und haben den agilen Gedanken, nicht alles auf einmal, sondern in kleineren und besser verdaulichen Stücken (How to slice the Elephant?), verinnerlicht. Unsere ganze Firma funktioniert mehr oder weniger nach diesem Prinzip. Auch wenn es jeden Tag etwas komplexer wird, so lernen wir auch jeden Tag etwas dazu.

Mit der Verkündung des agilen Manifests vor einigen Jahren hat sich dessen Intention und Mindset nicht direkt durchgesetzt; aber mit der Zeit, so dass wir heute sagen können, es handele sich um Allgemeingut, zumindest aus unserer Sicht. Dass nicht alle diese Sicht teilen und verinnerlicht haben, führt uns zum Fokus dieses Artikels, der nur eine Einleitung in eine Reihe weiterer themenbezogener Beiträge sein soll.

In dieser Themenreihe wollen wir aus unterschiedlichen Perspektiven und möglichst kontrovers beleuchten, was die Probleme unserer täglichen Arbeit sind, und was Projekte – insbesondere im Umfeld von Konzernen oder hierarchisch organisierten Systemen – daran hindert, erfolgreich zu sein. Es geht dabei um die aus unserer Sicht vernachlässigten, weil nicht als notwendig erachteten, Fähigkeiten einer Projektleitung, die günstigstenfalls unter dem Thema Soft-Skills subsumieren. Es geht um ein (Buzz-)Wort, das bei den meisten mit wenig echtem Inhalt oder konkreter Vorstellung aufgeladen ist; es geht um

CHANGE MANAGEMENT.

Wir glauben, dass mit einem etablierten und in Projekten eingeplanten Change Management zumindest vieles besser wäre - echte Belege fehlen uns hierfür jedoch noch, weswegen wir der Sache mit dieser Blog-Reihe und entsprechenden Fragen auf den Grund gehen wollen:

• Wie kann eine große Organisation zumindest am Rande so agil werden, dass eine Zusammenarbeit in rein agilen Projekten möglich wird?
• Was machen wir, wenn die Fachseite / Linienfunktion den agilen Ansatz nicht versteht und diesen politisch motiviert oder auch aus Unwissenheit immer wieder ad absurdum führt?
• Sind es politische oder kulturelle Widerstände in / von Organisationen, die Projekte scheitern lassen?
• Was kann man aus Sicht eines Dienstleisters aktiv tun, um ein Projekt erfolgreich zu machen, aber wann kämpfen wir gegen Windmühlenflügel?
• Gibt es wissenschaftliche, bspw. soziologische Ansätze, um den Problemen zu begegnen?
• Welches Handwerkszeug braucht man heute als Projekt- oder Programm-ManagerIn in größeren Projekten? Was ist wichtiger, technisches Verständnis, diplomatisches Geschick und Empathie oder Kenntnisse der Organisation, mit der man zusammenarbeitet?

Die Fragen dienen vorerst der Veranschaulichung wohin die Reise gehen könnte. Dem agilen Verfahren entsprechend wollen wir unsere Antworten iterativ entwickeln und geben einzelnen Autoren und Autorinnen, Fachleuten und Betroffenen die Möglichkeit, das Thema mit ihrer jeweiligen Sichtweise zu durchdringen und nähern uns auf diese Weise dem Kern. Entsprechend werden in den nächsten Monaten dazu verschiedene weitere Blog/Newsletter/Social-Media-Beiträge veröffentlicht, die hoffentlich zu einer regen, kontroversen Diskussion anregen, denn uns interessiert auch Ihre Sichtweise!

Als Auftakt wagen wir initial mal die These, dass wir aus Sicht des IT-Dienstleisters die Technik im Griff haben, aber mit wachsender Größe der Kunden-Organisation die Probleme im Projekt zunehmend aus der Organisation kommen. Auf die Spitze getrieben hieße dies, dass es ab einer gewissen Organisationsgröße einen Wendepunkt geben müsste, ab dem kein Projekt mehr wenigstens ohne größere Probleme, Verzögerungen oder Mehraufwand erfolgreich beendet werden kann. Wer schon mal in größeren Projekten bei Bahn, Post, Bundeswehr, Telekom o. ä. sein Brot verdient hat, wird ein Gefühl dafür haben, was hier gemeint sein könnte.

Wir freuen uns auf Euer Feedback!