{"id":20758,"date":"2017-04-21T14:57:19","date_gmt":"2017-04-21T12:57:19","guid":{"rendered":"http:\/\/e3mag.com\/?p=20758"},"modified":"2022-05-01T08:23:27","modified_gmt":"2022-05-01T06:23:27","slug":"wie-agil-reagieren-menschen-auf-veraenderungen","status":"publish","type":"post","link":"https:\/\/e3mag.com\/de\/wie-agil-reagieren-menschen-auf-veraenderungen\/","title":{"rendered":"Wie agil reagieren Menschen auf Ver\u00e4nderungen?"},"content":{"rendered":"

\"Chris<\/a>Ausgangspunkt f\u00fcr diesen Artikel ist ein gro\u00dfes Software-Entwicklungs- und -Einf\u00fchrungsprojekt einer neuen SAP-Software f\u00fcr mehr als tausend Anwender in einem internationalen Gro\u00dfunternehmen.<\/p>\n

Hierbei mussten zur bereits im System vorhandenen Standardfunktionalit\u00e4t einige f\u00fcr den Kunden essenzielle Funktionalit\u00e4ten komplett neu entwickelt sowie bestehende Prozesse zun\u00e4chst analysiert und zum Teil optimiert werden.<\/p>

\"\"<\/a><\/div><\/div>\n

Agile Methoden sind in aller Munde und werden oftmals als \u201eHeilsbringer\u201c f\u00fcr allerlei aus Software-Entwicklungsprojekten fr\u00fcherer Tage bekannte Probleme postuliert. Die relativ starre und lineare Vorgehensweise in der klassischen Wasserfall-(Projekt-)Methodik, bei der von der Bedarfsanalyse \u00fcber die L\u00f6sungsdefinition und der anschlie\u00dfenden, oft langwierigen Entwicklungs- und Testphase auf ein schon zu Beginn des Projekts vollst\u00e4ndig definiertes Endergebnis hingearbeitet wurde, barg zahlreiche Risiken, das eigentlich gew\u00fcnschte Ergebnis am Ende dann doch nicht zu erreichen.<\/p>\n

Zu viel Unvorhergesehenes konnte in den langen Projektlaufzeiten passieren: Anforderungen lie\u00dfen sich zu Beginn gar nicht vollst\u00e4ndig in jedem Detail definieren, Stakeholder \u00e4nderten sich w\u00e4hrend der Projektlaufzeit, Technologien waren am Ende des Projekts bereits wieder veraltet oder die urspr\u00fcnglichen Anforderungen haben sich schlicht w\u00e4hrend einer langen Entwicklungsphase ge\u00e4ndert oder waren pl\u00f6tzlich obsolet geworden.<\/p>\n

Da verspricht die iterative Vorgehensweise in agilen Projekt- und Entwicklungsmethoden deutlich mehr Flexibilit\u00e4t und Sicherheit, auf auftretende Ver\u00e4nderungen reagieren zu k\u00f6nnen.<\/p>\n

Kurze Entwicklungszyklen von typischerweise ein bis zwei Wochen erlauben es, \u00fcberschaubare Entwicklungspakete mit weniger Komplexit\u00e4t f\u00fcr die \u201eSprints\u201c zu definieren und zu liefern und in den darauffolgenden, immer wiederkehrenden Sprint Reviews mit den Auftraggebern auch auf sich \u00e4ndernde Anforderungen entsprechend flexibel reagieren zu k\u00f6nnen.<\/p>\n

Es dr\u00e4ngt sich fast der Eindruck auf, jedes agil organisierte (Entwicklungs-)Projekt m\u00fcsste folgerichtig automatisch zu einem Erfolg werden. Das ist jedoch leider nicht so.<\/p>\n

Ein erfolgreicher Abschluss der Entwicklungsarbeiten definiert noch lange nicht den Projekterfolg eines gro\u00dfen Softwareentwicklungsprojekts. Die Software kann noch so gut und zielgerichtet zu einem funktionierenden Endergebnis komplett neu entwickelt, angepasst oder entsprechend erweitert worden sein und auch die Anforderungen der Auftraggeber k\u00f6nnen vollumf\u00e4nglich erf\u00fcllt sein:<\/p>\n

Echter Projekterfolg ist erst dann erreicht, wenn die neue Software erfolgreich im Unternehmen ausgerollt wurde und von der breiten Masse der Anwender akzeptiert und genutzt wird.<\/p>\n

Die Einf\u00fchrung neuer Software geht meistens auch mit der Einf\u00fchrung neuer oder ver\u00e4nderter Prozesse einher. Prozesse jedoch, die von Menschen gelebt werden, lassen sich nicht \u201eagil\u201c einf\u00fchren oder ver\u00e4ndern \u2013 denn Menschen unterliegen immer noch unterschiedlichen Ver\u00e4nderungsgeschwindigkeiten.<\/p>\n

Da hilft auch keine noch so agile Projekt- oder Entwicklungsmethode. Wird der \u201eFaktor Mensch\u201c nicht rechtzeitig wahr- und ernstgenommen, endet auch das agilste Softwareprojekt im Bestfall mit einer tollen Software, die zwar dem Auftraggeber und vielleicht noch einigen Stakeholdern gef\u00e4llt, aber von der breiten Masse der User gar nicht oder nur ineffizient genutzt wird.<\/p>\n

Der Erfahrung nach steigt das Erfolgsrisiko mit der Gr\u00f6\u00dfe der sp\u00e4teren Nutzergruppe (oder des Unternehmens), weil eben oftmals doch keine repr\u00e4sentative Gruppe der finalen Endanwender in den Feedbackrunden der einzelnen Entwicklungszyklen beteiligt war.<\/p>\n

Zum einen wird in der Zusammenstellung der Stakeholder, speziell auch der f\u00fcr die Sprint Reviews, gern dazu tendiert, die ohnehin engagierten und eher ver\u00e4nderungsaffinen Mitarbeiter auszuw\u00e4hlen.<\/p>\n

Dar\u00fcber hinaus ist es schlicht ein Problem von Masse: Bei mehr als 1000 betroffenen Endanwendern und wom\u00f6glich mehreren betroffenen Prozessen ist die Wahrscheinlichkeit sehr gro\u00df, dass die kleine Kerngruppe, von denen in der Sprint-Phase aktiv Feedback eingeholt wird, einfach nicht repr\u00e4sentativ ist.<\/p>\n

Was also tun, um ein Software-Entwicklungsprojekt mit einer gro\u00dfen Anzahl betroffener Anwender bestm\u00f6glich auf den Erfolgspfad zu bringen?
\nAus unserer Sicht gilt es, die Vorteile moderner, agiler Methoden mit denen klassischer Methoden aus dem Projektmanagement und der Organisationsentwicklung zu kombinieren: agil entwickeln, klassisch ausrollen.<\/p>\n

Im diesem Artikel zugrunde liegenden Software-Einf\u00fchrungsprojekt mit mehr als tausend betroffenen Anwendern wurde auf das bew\u00e4hrte Sirius-Projektvorgehen zur\u00fcckgegriffen, bei dem die Vorteile der agilen Scrum-Methodik mit klassischen Projektmanagement-Vorgehensweisen und des organisatorischen Change-Managements kombiniert werden.<\/p>\n

Es wird dabei schon m\u00f6glichst fr\u00fchzeitig versucht, mehrere Kommunikations- und Interaktionskan\u00e4le zu m\u00f6glichst vielen (potenziell allen) End\u00adanwendern aufzubauen.<\/p>\n

Ein Integrieren nur einiger ausgew\u00e4hlter \u201eKey-User\u201c ist aus unserer Sicht nicht ausreichend, um die Akzeptanz der einzuf\u00fchrenden neuen Software und ggf. anstehender Prozess\u00e4nderungen zu erreichen. Vielmehr muss gerade in die gern aufgrund von Zeit-, Geld- und Ressourcenmangel weggelassenen Themenkomplexe Kommunikation und Ver\u00e4nderungsmanagement deutlich mehr investiert werden \u2013 und zwar von Beginn des Projekts an.<\/p>\n

Es kann nicht zu viel Information und Transparenz zu den bevorstehenden \u00c4nderungen geben \u2013 nur zu wenig!<\/p>\n

\"Sirius<\/a><\/p>\n

Phasen der Sirius- Projektmethodik<\/h3>\n

Konkret hat es sich auch im vorliegenden Projekt wieder bew\u00e4hrt, auf folgende Punkte in den einzelnen Projektphasen ein ganz besonderes Augenmerk zu legen:<\/p>\n

Scoping<\/h4>\n