Agil versus Wasserfall, "Big Design Up Front" versus  "organisch gewachsenes System" - das WWW ist voll von Best Practices und Modellen mit Erfolgsgarantie die von den Evangelisten der jeweiligen Strömung angepriesen werden.

​

Unsere Erfahrung hat gezeigt, dass jedes Vorgehensmodell an die jeweilige Situation und den Reifegrad der Gesamtorganisation angepasst werden muss. Es gibt aber doch ein paar Grundsätze die bei der  Auswahl der richtigen Vorgehensweise beachtet werden müssen:

​

• Ausgangspunkt jeder Initiative ist der erwartete Kundennutzen, egal ob der Anstoß aus der Geschäftsleitung, dem Fachbereich oder der IT kommt.
  Bewährt hat sich die Erarbeitung eines Scoping - Dokumentes mit den Inhalten

  • erwarteter Nutzen

  • Stakeholder

  • Inhalte / Themen

  • Nicht - Inhalte ("Out of Scope")

• Am Anfang jeder Initiative muss der aktuelle Wissenstand (IST - Situation, SOLL - Zustand, Umfeld) schriftlich, am besten grafisch Aufbereitet, festgehalten werden. Das muss immer in Kooperation zwischen Fachbereich und Technik erfolgen, die Dokumentation muss daher auch für beide Seiten verständlich sein.

• Vor der Implementierung muss es eine grobe Beschreibung des Lösungsvorschlages (High Level Solution Design / Architecture) geben. Weniger ist hier mehr, im Zuge der Entwicklung wird sich das sicher Ändern.

• Die Entwicklung muss iterativ Erfolgen, unabhängig vom gewählten Vorgehensmodell. Im Zuge jeder Entwicklung steigt der Wissensstand und die Fähigkeiten auf allen Seiten (Fachbereich und IT). Iterativ heißt, dass sich "Anforderungen", technisches Design und auch die Zielprozesse  während der Entwicklung verändern können. Diese Änderungen müssen laufend mit dem "Scope" abgeglichen werden, um den Rahmen des Projektes nicht zu verlassen.

• (Zwischen-) Ergebnisse der Entwicklungen müssen in die Business Prozesse  integriert werden, um die gewünschten Optimierungen auch wirklich zu realisieren. Das klingt trivial, wird aber sehr oft nicht berücksichtigt.

• Betriebsprozesse sind nicht agil und nicht iterativ. Die Übergabe von der Entwicklung in den Betrieb ist Mission - Critical und muss bei der Wahl des geeigneten Vorgehensmodelles berücksichtigt werden.

​

Abhängig von Kontext, Projektgröße / Komplexität müssen die Rollen im Projekt (nicht zuletzt aus budgetären Gründen) definiert werden. Bei kleineren Initiativen kann der Projektleiter gleichzeigt die Agenden des Analysten, Architekten und Testmanager wahrnehmen (in diesem Fall empfehlen wir jedoch ein unabhängiges Projekt - Controlling), in größeren Initaitiven werden diese Rollen vermutlich durch unterschiedliche Personen wahrgenommen - wobei dann der "Overhead" natürlich deutlich steigt.