Was wäre, wenn wir Projekte ereignisgesteuert abwickeln würden?
Im letzten Beitrag habe ich eine Fallstudie eines gewöhnlichen Migrationsprojekts vorgestellt, das wegen ein paar kleinen IT-Fehlern einen Schaden von 160 Mio US-Dollar verursachte. Es ist unmöglich, alle IT-Fehler auszumerzen, weil auch bei unendlichem Aufwand immer eine Ungewissheit bleibt, was sich alles ereignen kann, auf das die Software reagieren sollte. Daher ist Risikomanagement eine Aufgabe des Business‘ und nicht der IT. Dennoch wird die Verantwortung nach wie vor auf die subsidiären Unternehmensteile abgewälzt. Was tut die IT, um diese Verantwortung wahrzunehmen? Sie zertifiziert ihre Projektmanager in klassischen Projektmanagementmethoden, die aber offensichtlich wenig taugen, wie die Fallstudie zeigt (und wie ich […]
Nicht-Einhalten klassischer Projektmethodiken als Grund des Scheiterns?
Stephan Schori schrieb am 22 Februar 2009 in einem Kommentar: Ausserdem ist nach meiner Meinung auch bewiesen, dass, je komplexer und umfangreicher die Projektmethodiken und entsprechenden Dokumente sind, desto kleiner die Erfolgsquote ist, da zwar wohl alle Schritte durchgemacht und dokumentiert werden, ein Review und eine Gesamtbeurteilung aber nicht mehr stattfindet, ganz nach dem Motto: ein Haufen Backsteine macht noch kein Haus! Nach meiner Erfahrung liegt das Hauptproblem bei gescheiterten Problemen nicht in komplexen und unverständlichen Modellen und der Fähigkeit, “positive von negativen Rückkopplungen unterscheiden zu können (!)”, sondern zu 90% darin, dass schon die klassischen Projektmethodiken nicht eingehalten werden […]